-1

自動インクリメントとUUIDスタイルの本当の違いは何ですか？

autoincはuuidに対してハッキングしやすいと思います

Uuidは、多くのレコードを含むクエリの自動インクリメントよりも低速ですが、大きな違いはありますか？

4

4 に答える 4

4

主キーは、リレーショナル モデルの観点から非常に重要です

  • 一意性は迅速にチェックする必要があります
  • 他のテーブルで外部キーとして使用
  • 参加していた

PK は小さいほど良い。そのため、数値PK が最適です。

「ハッキング」されやすいことが懸念される場合は、追加の UUID を自然キーとして追加できます。

  • 行への「直接アクセス」にのみ使用

それは私がいくつかのプロジェクトで見たもので、魅力的に機能しました。

于 2010-03-04T10:12:54.060 に答える
2

インクリメント ID 自体は「ハッキングするのは簡単」ではありません。大きなランダム ID を使用すると、隠されている (完全に隠されているわけではありません) エントリ ポイントが提供されるだけです。真の危険があるためには、実装が不十分で悪用可能なソフトウェアが必要です。アドレス バーの URL でわかるように、このサイトは増分 ID を問題なく使用しています。

ただし、セキュリティ上の考えは別として、ランダムな一意の ID は、ユーザーが他の (公開されているとはいえ) コンテンツの URL を簡単に推測できないようにする場合に役立ちます。たとえば、不動産サイトでは、競合他社のエントリを見て、ID を「上下」に移動する可能性を提供したくない場合があります。たとえ、競合他社がすべての検索でそれらを見つけることができたとしてもです。少しの障害は良いことかもしれません。

両方を使用しないのはなぜですか？インデックス作成とリレーションを高速化する数値自動インクリメント キー。外部アクセス用のランダムな UID。

于 2010-03-04T09:54:28.400 に答える
1

いくつかの考え:

  • auto-inc: DB は一意の ID を保証しますが、それを取得するか、挿入したばかりのデータ レコードへの「連絡先」を失う必要があります。
  • UUID: 「外部」で作成する必要があります (db サーバーではなく、app-server にある可能性があります)。ID は既知であり、挿入されたレコードへのリンクは存在しますが、(非常に小さいですが、uuid の uuid ネスに依存します) 挿入時に衝突のリスクがあります。
于 2010-03-04T09:55:10.600 に答える
0

PK 列の長さに注意してください... UUID と GUID は非常に長い... 文字列です。INT または BIGINT 自動インクリメント列でさえ、はるかに小さなスペースで一意性を確保できます。

自動インクリメント列には、テーブル管理に関する独自の問題がいくつかあることに注意してください。テーブルを切り捨て/ドロップ作成すると、自動インクリメントを維持するのが難しくなります。また、MySQL では、1 つのテーブルに対して 1 つの自動インクリメント カラムのみが許可されます。

データで許可されている場合は、インデックス作成とパフォーマンスのために、データから派生したある種の HASH を使用します。

于 2010-04-06T20:22:31.333 に答える