mysql - 自動インクリメントIDまたはsha1ハッシュを使用する主キーmysql？

Question

主キーとして自動インクリメントIDフィールドを使用することも、sha1ハッシュを使用することもできます。

どちらを選ぶべきですか？

パフォーマンスの点でどちらが良いでしょうか？

Answer 1

グローバルに一意のID（UUID / GUID）を使用したいアプリケーション主導のケースがいくつかあります。

1. 書き込みをスケーリングするためにシャーディング戦略を使用することを期待しています（または使用しています）。シャードノードがキーを複製することは望ましくありません。
2. あるノードから別の保存キーにデータを安全に 移植できるようにする必要があります。これは、外部キー関係をそのまま維持したい場合に重要です。
3. アプリケーションはオフラインでも使用され（家の販売、家の修理など）、オフラインのアプリケーションは定期的に「信頼できる情報源」と同期します。リモート呼び出しを行わなくても、これらのオフラインキーを一意にする必要があります。それ以外の場合は、途中でキーと関係を再編成する戦略を考え出すのはあなた次第です。自動インクリメント戦略では、使用しているRDBMSによっては、これは簡単な作業ではない可能性があります。

上からのユースケースなどがない場合は、快適であれば自動インクリメントIDを使用できます。ただし、UUID/GUIDを検討することもできます

トレードオフ：

UUID/GUIDキーの速度/サイズについては多くの意見があります。結局のところ、これはトレードオフであり、データベースを使用して速度を上げたり下げたりする方法はたくさんあります。理想的には、可能な限り高速にするために、インデックスをRAMに格納する必要があります。ただし、これは他の考慮事項と比較検討する必要があるトレードオフです。

UUID / GUIDに関するその他の考慮事項：

1. 多くのRDBMSはUUIDを生成できます。
2. アプリケーションを介してUUIDを生成することもできます（生成するRDBMSに縛られていません）。
3. 開発者/テスターは、環境から環境にデータを簡単に移植し、アプリケーションを期待どおりに動作させることができます。これは見過ごされがちなユースケースです。ただし、これはUUID/GUID戦略を使用するためのより強力なケースの1つです。
4. オフラインでの使用に最適化されたデータベース（CouchDB）があり、UUIDが取得されます。

Answer 2

自動インクリメントIDを使用します。

• IDは、インクリメントするだけで生成する必要はありません。
• ハッシュはパスワードの保存に適しています。
• SHAハッシュを使用して重複キーを取得できます。チャンスは小さいですが、現実的です。
• IDの方がはるかに読みやすい
• IDは一種の挿入履歴です。どのレコードが最後に挿入されたかがわかります（最大ID）

Answer 3

ほぼ間違いなく、自動インクリメント整数。作成が速く、検索が速く、小さくなります。たとえば、それを参照する別のテーブルがある場合を考えてみます。統合主キーまたはsha1ハッシュを介して参照しますか？整数は（ある意味で）より意味があり、はるかに（はるかに！）効率的です。