language-agnostic - ID 列に推奨されるデータ型は?

Question

この質問は以前に尋ねられた可能性が非常に高いと思いますが、StackOverflow に関する質問を少し検索しましたが、実際には答えが見つからなかったので、ここに行きます。重複を見つけた場合は、リンクしてください。

なんらかの理由で、主キーフィールドにGuids ( uniqueidentifierMsSql 内) を使用することを好みますが、なぜこれが優れているのかはよくわかりません。最近、私が自分で説明した多くのチュートリアルでは、自動インクリメントintが使用されています。私は両方で長所と短所を見ることができます：

AGuidは常に同じサイズと長さであり、それらが不足することを心配する理由はありませんが、に収まる数値が不足する前に保持できるレコード数には制限がありますint。
int(少なくとも C# では) null 許容型であり、データのクエリを実行するときにいくつかのショートカットが開きます。
そしてint読みやすくなっています。
ここで、少なくともさらにいくつかのことを思い付くことができると思います。

タイトルが示すように単純です:データベースの ID (主キー) 列に推奨されるデータ型は何ですか?

編集:いくつかの短い回答を受け取った後、このフォローアップの質問も追加する必要があります。それがなければ、あなたの答えは説得力がなく、教育的でもありません... ;)なぜそう思うのですか？

score 16 · Accepted Answer

予想されるデータ範囲を格納するのに十分なサイズの任意の整数型。一般に、32 ビット int は、多くの行または変更を含むテーブルに対して (正しいか間違っているかを問わず) 小さすぎると見なされます。64 ビットの int で十分です。多くのデータベースは、その整数型を持っていないか使用しませんが、指定された位取りと精度を持つ NUMBER 型を使用します。10 ～ 15 桁が一般的なサイズです。

整数型を選択する理由は 2 つあります。

サイズ; と
スピード。

整数のサイズは次のとおりです。

32 ビット: 4 バイト。
64 ビット: 8 バイト。
2 進化 10 進数: 1 バイトあたり 2 桁と、符号、位取り、および/または精度用の 1 バイト。

これを 128 ビットまたは通常の文字列であるGUIDと比較してください。これは、1 文字あたり少なくとも 1 バイト (特定の文字エンコーディングではより多い) に加えて、わずか 1 バイト (null で終了) またはそれ以上になる可能性があるオーバーヘッドです。ある場合には。

整数のソートは自明であり、それらが一意であり、範囲が十分に小さいと仮定すると、せいぜい O(n log n) と比較して、実際には O(n) 時間で実行できます。

また、同様に重要なことに、ほとんどのデータベースは自動インクリメントカラムやシーケンスによって一意の ID を生成できます。それ以外の場合、アプリケーションで一意性を保証することは実際には非常に難しく、キーが肥大化する傾向があります。

さらに、自動生成された整数キーは通常、(データベースと構成に応じて) 緩やかにまたは完全に順序付けられます。これは有用な品質です。ランダムに生成された GUID は基本的に順序付けされていないため、あまり役に立ちません。

score 7 · Accepted Answer

人気のあるデータベースでは、何年もの間、より大きな自動インクリメントフィールドが許可されているため、それほど問題になりません。

何を使用するかについては、常に選択です。一方が他方より明らかに優れているわけではありません。それらには異なる特性があり、それぞれが異なるシナリオで優れています。私は長い間両方を使用してきましたが、次に使用するスキーマでは両方を検討します。

GUID の利点:

コンピューター間で一意である必要があります。
ランダムで記憶に残らないグーは、人々が不透明な識別子という意図された目的のためにのみこれを使用する可能性が高いことを意味します。

自動インクリメントの長所:

人間理解可。
順次割り当てとは、クラスター化インデックスを使用してパフォーマンスに影響を与えることができることを意味します。
データの分割に適しています。

score 6 · Accepted Answer

GUID キーを使用することの大きな欠点は、「アドホック」クエリを手動で実行するのが難しいことです。これを行うことができると非常に便利な場合があります。

SELECT * FROM User where UserID=452245

GUID キーを使用すると、これは非常に煩わしくなります。

64ビット整数をお勧めします

score 2 · Accepted Answer

long を使用すると、1 秒間に 1000 個以上作成でき、2900 万年間主キーが不足することはありません。

他の人は、UUID/GUID の代わりに整数型を使用することのいくつかの利点について既に言及しています。大きな利点の 1 つは、インデックスの速度とコンパクトさです。

私が最近関わったデータベース設計のアプリケーションでは、UUID が必要でしたが、主キーに long を使用する利点を放棄したくありませんでした。システムを UUID に変更します。すべての主キーは単一のシーケンスから生成されたため、すべてのテーブルですべて一意でした。

score 2 · Accepted Answer

重要だと思う基準を教えてください。

必要なのは、テーブル内で一意であることです。

GUID は、グローバルな確率的に一意の識別子です。それも大きい。インデックスを、宇宙の他のすべてのデータベースインストールよりもイプシロン内で一意にする必要がある場合は、これが適切な選択です。そうしないと、不必要に多くのスペースを使用しています。

自動インクリメント番号は適切です。それは小さく、テーブル内で一意であることは間違いありません。一方、重複に対する保護はありません。マジックナンバーを除いて同一の 2 つのエントリは、簡単に作成できます。

記述されているエンティティに関連付けられている値を使用すると、それを回避できますが、一意性を処理するという問題があります。

score 0 · Accepted Answer

クレタスのアドバイスに従ってください。追加の注意事項は、あなたのストーリーに大きく依存します。GUID は絶対に使用しないでください。GUID にはさまざまな欠点があり、利点は 1 つまたは 2 つだけです。

score 0 · Accepted Answer

データベースが分散していて、他のデータベースからレコードを取得できる場合、主キーはすべてのデータベースでテーブル内で一意である必要があります。GUID はこの問題を解決しますが、スペースが犠牲になります。自動インクリメントと名前空間の組み合わせは、適切なトレードオフになります。

データベースが「プレフィックス」を使用した自動インクリメントの組み込みサポートを提供できるとよいでしょう。したがって、あるデータベースでは X1、X2、X3 ... などの ID を取得しますが、他のデータベースでは Y1、Y2、Y3 ... などの ID を取得します。

score 0 · Accepted Answer

役立つかもしれないいくつかの答えがある同様の質問をしました。レプリケーションは、GUID を使用する最大の利点のようです。

主キーに自動インクリメント番号を使用しない理由

language-agnostic - ID 列に推奨されるデータ型は?

9 に答える 9

Related

Reference