主キーにハッシュを使用することは良い考えですか？
オーストリアの電子IDカード は、いわゆるセクター識別子に依存しています。たとえば、病院では、大まかに次のように計算される、その人のセクターIDを取得することで、その人を識別できます。
sha1(personalId + "+" + prefix + sectorId); // prefix is constant and irrelevant
それは良い考えですか？どんなに小さくても、衝突の可能性は危険だと思います。
ハッシュテーブルでは、衝突が発生した場合、同等性を確立する別の方法がありますが、主キーでは、2つを同一にすることはできません。これは複合キーによって回避できますが、一意のセクター識別子のポイントが失われます。
それをしても大丈夫ですか？それがどこかで壊れることなくそのようにする方法はありますか？
この前者SO記事 は、衝突確率の計算方法を示します。SHA-1の場合、bは160です。オーストリアに住んでいる人の数は1000万人未満です。オーストリアの各居住者が一意の個人/セクターIDで病院に登録されている場合でも、衝突確率は3.5 x 10^-35未満になります。ほとんどの実用的な目的では、これは十分に小さいはずです。
ハッシュは、データの可能なすべての組み合わせよりも小さい場合、必然的に衝突します。
この優れた答えをご覧ください： https://softwareengineering.stackexchange.com/a/1456
主キーが意味のあるものではない場合（人間が読み取り可能、データの取得可能な特性を含む）、GUIDを使用します。
はい、理論的には衝突する可能性もありますが、宇宙の熱死が最初に発生する可能性があります。参照してください https://stackoverflow.com/a/184897
編集：@DocBrownのカウンターポイントに対処して、問題を明確にします（コメントでの長い議論を避けるため）。
人IDまたはセクターIDから識別子を生成することはOPの要件ではありませんでした（実際、彼はGUIDに頼ることが彼自身の提案であると認めました）。
GUIDがSHA-1の全体的な置き換えとして適しているとは決して言いませんでした、または一般的にハッシュは（もちろんそうではありません）、これらはこの特定の場合に使用できると言っているだけです-いくつかのエンティティを一意に識別するために。これは、定義上、その目的のためです。
これらの識別子がデータから再構築可能である必要はありませんでした（これはハッシュ関数の利点です）。実際の質問のコンテキスト内で私の回答を評価してください。
ハッシュまたはGUIDを主キーとして使用することも、インデックスの断片化と頻繁なページ分割を引き起こすため、お勧めできません。