主キーにハッシュを使用することは良い考えですか？

オーストリアの電子IDカードは、いわゆるセクタ識別子に依存しています。たとえば、病院では、大まかに次のように計算される、その人のセクターIDを取得することで、その人を識別できます。

sha1(personalId + "+" + prefix + sectorId); // prefix is constant and irrelevant

それは良い考えですか？どんなに小さくても、衝突の可能性は危険だと思います。

ハッシュテーブルでは、衝突が発生した場合、同等性を確立する別の方法がありますが、主キーでは、同一の2つを使用することはできません。これは複合キーで回避できますが、一意のセクター識別子のポイントが失われます。

それをしても大丈夫ですか、それがいつか壊れることなくそのようにする方法はありますか？

design programming-practices database-design

— 坊主
ソース

このアルゴリズムが重複を作成する場合でも、重複を許可しないインデックスを持つシステムの他のチェックはありませんか？IDカードなしで別の病院に行く場合、この番号以外に個人を検索する方法はありませんか？

— JeffO、2015

ハッシュアルゴリズムを使用する意味は何ですか？personalId+ sectorIDはすでに一意の識別子として機能し、非表示にする必要のあるパスワードのようなものは何もないため、ハッシュは実際には使用されていないようです。何が欠けていますか？または「personID」は何か秘密ですか？

— Doc Brown

通常（V4）が160ビットの122個のランダムビットで構成されるUUIDを信頼するのはなぜですか？後者の場合、偶発的な衝突は明らかにまれです。

— CodesInChaos 2015

@DocBrown自分自身に興味がありました。だから、私はそれを上で見つけてリンクしました。約10秒で興味がなくなったので、要点はよくわかりませんが…プライバシーと関係があると思います…。

— svidgen 2015

あなたがより良いハッシュを選ぶなら、地球上の人間は単一の衝突さえも作成する方法を知りません。多くの人が試しました。

— usr

回答:

この以前のSOの記事では、衝突確率を計算する方法を説明しています。SHA-1の場合、bは160です。オーストリアに住んでいる人の数は1000万人未満です。オーストリアの各居住者が一意の人物/セクターIDで病院に登録されている場合でも、衝突の確率は未満になり3.5 x 10^-35ます。これは、ほとんどの実用的な目的には十分小さいはずです。

— ドク・ブラウン
ソース

まあ、あなたはそれが生と死についてであるとき、その議論が陪審にとって非常に重要であると確信していますか？

— Deduplicator 2015

@Deduplicator：ハードウェア障害（RAMまたは磁気ストレージの一部のビットの反転）または人的障害（タイプミスなど）が原因で衝突が発生する可能性は、IDやハッシュの種類に関係なく、はるかに高くなります使用されている。しかし、もちろん、ペティフォガーはこれとは異なる場合があります。

— Doc Brown、

私のポイントは、どの弁護士もおそらく1人であるということです... ;-)

— 重複排除

ハッシュは、データの可能なすべての組み合わせよりも小さい場合、必然的に衝突します。

この素晴らしい答えを見てください：https : //softwareengineering.stackexchange.com/a/145633

主キーが意味のあるものではない場合（人間が読み取り可能、データの取得可能な特性を含む）、GUIDを使用します。

はい、理論的には衝突する可能性もありますが、宇宙の熱死が最初に発生する可能性があります。https://stackoverflow.com/a/184897を参照してください

編集：物事を明確にするために（そしてコメントでの長い議論を避けるために）@DocBrownのカウンターポイントに対処する

個人IDまたはセクターIDから識別子を生成することは、OPの要件ではありませんでした（実際、彼は、GUIDに頼ることが彼自身の提案であると認めました）。

GUIDがSHA-1の全体的な置き換えとして適しているとは決して言いませんでした、または一般的にハッシュは（もちろんそうではありません）、これらはこの特定のケースで使用できると言っているだけです-いくつかのエンティティを一意に識別するために。これは、定義上、その目的のためです。

これらの識別子がデータから再構築可能である必要はありませんでした（これはハッシュ関数の利点です）。実際の質問のコンテキスト内で私の答えを評価してください。

— コンラッド・モラウスキー
ソース

@Bozho私はあなたの提案がそれと同じくらい良いと思います。ランダムな128ビットの識別子を使用することで、物事は単純になり（すでに大きな利点があります）、必要に応じて、常にこれらの値の前に意味のあるものを付けることができます。唯一の欠点は、結果の値が長くなることですが、すべてを取得できるわけではありません。いずれにしても、通常は誰にも表示されないのではないでしょうか。一部のPINは電話で引用することが予想されるため、使用されません。

— Konrad Morawski、2015

GUIDには128ビットがあり、SHA1は160ビットの出力を生成します。では、彼の質問で言及されているOPのハッシュよりも、SHA1ハッシュよりもGUIDの方が良い選択であるとあなたが信じる理由は何ですか？

— Doc Brown、

@DocBrown私は確かにその分野の専門家ではありませんが、出力の長さ自体は問題ではありません。ハッシュ関数は同じ入力に対して同じ出力を返します（つまり、一種のポイントです）。personalId + "+" + prefix + sectorId一意であることが保証されている場合は、おそらくそのまま使用することもできますが、そうでない場合、SHA1は追加の一意性を追加しません。問題は-私が理解しているように-このシステムは、特にシステムが長期間機能することが期待される場合、一意の出力を生成しない可能性があることです（保守性の理由により、たとえばセクターIDの追加が必要になる場合があります-注意してください）

— Konrad Morawski

ここでもGUIDがどのように役立つのかわかりません。GUIDの使用はハッシュアルゴリズムではありません。GUIDはpersonID / ectorIDから生成できません。一意のpersonIDの生成が問題にならない場合（おそらくそうではない）、後者の代替として使用できますが、SHA-1などの代わりにはなりません。

— Doc Brown

私見GUIDはOPの問題を解決していません。GUIDは分散された方法で一意の識別子を生成するのに役立ちます-「オーストリアのベースレジスタ」はかなり集中化された機関であり、その問題はありません-personalId +セクターコードはすでに一意のIDです。なぜより複雑にするのですか？興味深い質問は、なぜハッシュを適用するのかということです。しかし、それはOPが私たちに告げることを期待するものです。

— Doc Brown、

ハッシュまたはGUIDを主キーとして使用することも、インデックスの断片化と頻繁なページ分割の原因となるため、お勧めできません。

— ゴードンベル
ソース