PHP によって生成された一意の ID を、10,000 を超えるレコードを持つことのないデータベース テーブルで使用したいと考えています。作成時間を表示したり、純粋な数値を使用したりしたくないので、次を使用しています。
sha1(uniqid(mt_rand(), true))
一意の ID にハッシュを使用するのは間違っていますか? すべてのハッシュが衝突につながるわけではありませんか、それとも可能性が非常に低いため、この場合は考慮すべきではありませんか?
さらなるポイント: ハッシュされる文字数が sha1 ハッシュの文字数よりも少ない場合、それは常に一意ではないでしょうか?
キーが 2 つある場合、衝突の確率が 2 ^ X に 1 という理論上の最良のシナリオが得られます。ここで、X はハッシュ アルゴリズムのビット数です。入力は通常、完全な文字セットを利用しない ASCII であり、ハッシュ関数は完全に分散されないため、実際には理論上の最大値よりも頻繁に衝突するため、「最良のケース」です。
最後の質問に答えるには:
さらなるポイント: ハッシュされる文字数が sha1 ハッシュの文字数よりも少ない場合、それは常に一意ではないでしょうか?
ええ、それは本当です。ただし、そのサイズの一意のキーを生成するという別の問題があります。通常、最も簡単な方法はチェックサムです。そのため、十分なサイズのダイジェストを選択して、衝突スペースが十分に小さくなるようにしてください。
@wayne が示唆するように、一般的なアプローチはmicrotime()、ランダムなソルトに連結する (そしてbase64_encodeエントロピーを上げる) ことです。
2人が同じ結末になったら、どれほど恐ろしいことになるでしょうか。マーフィーの法則が適用されます。100 万分の 1、または 100,000 分の 1 の確率が許容される場合は、すぐに実行してください。実際の可能性ははるかに小さいですが、システムが爆発する場合は、最初に設計上の欠陥に対処する必要があります. その後、自信を持って進みます。
確率が実際に何であるかについての質問/回答は次のとおりです。 SHA1衝突の確率
コンピュータのランダムは、実際にはランダムではありません。Unix 環境を使用していると仮定して、コンピューターから取得できる唯一の真のランダムは からのものですが/dev/random、これは、マウスの移動やキーボードでの入力などのユーザー操作に依存するブロック操作です。からの読み取り/dev/urandomは安全ではありませんが、おそらく ASCII 文字だけを使用するよりも優れており、即座に応答が得られます。