定期的なエンティティ（YouTubeのビデオ、または私のようなサイトの本のセクション）の一意の識別子の表示を何らかの方法で表示するWebアプリケーションを作成する場合、ハッシュや一意のような均一な長さの識別子を使用する方がよいでしょうかデータベース内のアイテムのキー（1、2、3など）。
少しだけ明らかにするだけでなく、アプリの内部に関する情報は重要ではないと思いますが、ハッシュを使用する方が、一意のIDを使用するよりも優れているのはなぜですか？
要するに：公開されている一意の識別子として使用するのに適しているのは、ハッシュ値とデータベースの一意のキーのどちらですか？
編集：Dmitriyが名前をdb固有のプロパティに結び付けないという良い点を提起したので、私はこの質問を再び開きます。この種のタイダウンにより、将来データベースを最適化/正規化できなくなりますか？
プラットフォームは、ISAM /wMySQLでphp/pythonを使用します。
内部オブジェクト ID カウンターの状態を隠そうとしない限り、ハッシュは不必要に遅く (生成して比較するため)、不必要に長く、不必要に醜く、不必要に衝突する可能性があります。GUID も長くて醜いため、ハッシュと同じように人間が消費するのには適していません。
インベントリのようなものについては、代わりにシーケンシャル (またはシャード) カウンターを使用してください。別のデータベースに移行する場合は、少なくとも既存の最大のレコード ID と同じ大きさの値に新しいカウンターを初期化する必要があります。ほぼすべてのデータベース サーバーで、これを行う方法が提供されています。
カウンターの状態を隠そうとする場合、おそらくユーザーをカウントしていて、競合他社にユーザー数を知られたくないという理由で、内部 ID の表示を避けることをお勧めします。それらを表示することを主張し、ハッシュの欠点を望まない場合は、最大期間の線形フィードバック シフト レジスタを使用して ID を生成することを検討してください。
ユーザーがシリーズの次の ID を推測できないようにする場合は、通常、ハッシュを使用します。しかし、あなたの本のセクションについては、数値の ID に固執します。
たとえば、何らかの理由でデータベースを再構築する必要があり、順序が変更された場合は、ハッシュを使用することをお勧めします。序数は移動しますが、ハッシュは同じままです。
箱に物を入れる順番に頼るのではなく、物の特性に頼った方が安全に思えます。
しかし、明らかに、衝突に気をつけてください。
ハッシュは一意であることが保証されておらず、一貫性があると私は信じています。
ユーザーは値を覚えたり使用したりする必要がありますか? それとも、セキュリティの視点から見ていますか?
セキュリティの観点からは、それは問題ではありません。なぜなら、彼らを締め出すために、彼らが見るべきではない何かの別の有効な ID を推測していない人々に頼るべきではないからです。
ハッシュを探しているのではなく、Guid を探している可能性が高いと思います。.Net プラットフォームを使用している場合は、System.Guid を試してください。
ただし、Guid を使用しない最も重要な理由は、パフォーマンスのためです。(長い) 文字列に対してデータベースの結合と検索を行うことは、最適ではありません。数字は速いです。したがって、本当に必要でない限り、実行しないでください。