database - GUID と INT IDENTITY

Question

重複の可能性:
主キーはどうですか?

GUID を使用する利点と、データベースで PK として INT を使用する利点を認識しています。GUID は本質的に 128 ビットの INT であり、通常の INT は 32 ビットであることを考慮すると、INT は省スペースです (ただし、この点は最近のほとんどのシステムでは一般的に意味がありません)。

最後に、どのような状況で INT を GUID ではなく PK として使用すると思いますか?

score 26 · Accepted Answer

Kimberley Tripp (SQLSkills.com) には、 GUID を主キーとして使用する方法に関する記事があります。不必要なオーバーヘッドがあるため、彼女はそれに対してアドバイスします。

score 23 · Accepted Answer

あなたの質問に答えるには: 最終的に、どのような状況で INT を GUID ではなく PK として使用すると思いますか?

システムにオンライン/オフラインバージョンがあり、オフラインバージョン内でデータを保存でき、そのデータが同期中に 1 日サーバーに転送される場合は、GUID を使用します。そうすれば、データベース内で同じキーが 2 回使用されることはありません。

score 22 · Accepted Answer

非常に複雑なエンタープライズソフトウェアのどこにでも Guid があります。スムーズに動作します。

Guid は識別子として機能するのに意味的に適していると思います。また、その問題に直面するまでパフォーマンスについて不必要に心配しても意味がありません。時期尚早の最適化に注意してください。

あらゆる種類のデータベース移行にも利点があります。Guid を使用すると、衝突は発生しません。ID に int が使用されている複数の DB をマージしようとすると、それらの値を置き換える必要があります。これらの古い値が URL で使用されていた場合、SEO ヒット後に異なるものになります。

score 20 · Accepted Answer

複数のデータベースインスタンスを同期する必要がある場合に不適切な選択であることに加えて、INT には言及されていない欠点が 1 つあります。挿入は常にインデックスツリーの一方の端で発生します。これにより、移動の多いテーブルがある場合にロックの競合が増加します (同じインデックスページを同時挿入で変更する必要があるのに対し、GUID はインデックス全体に挿入されるため)。B* ツリーまたは同様のデータ構造が使用されている場合は、インデックスをより頻繁に再調整する必要がある場合もあります。

もちろん、手動でクエリを実行してレポートを作成する場合は int の方が見やすく、FK の使用によってスペースの消費が増える可能性があります。

たとえば、SQL Server が IDENTITY PK を使用して挿入の多いテーブルを実際に処理する方法などの測定値を確認したいと思います。

score 14 · Accepted Answer

INT は省スペースです (ただし、この点は最近のほとんどのシステムでは一般的に意味がありません)。

そうではありません。一見そのように思えるかもしれませんが、各テーブルの主キーは、データベース全体でインデックス内および他のテーブルの外部キーとして複数回繰り返されることに注意してください。また、そのテーブルを含むほぼすべてのクエリに関与します。結合に使用される外部キーの場合は、非常に集中的に関与します。

さらに、最新の CPU は非常に高速ですが、RAM の速度が追いついていないことを忘れないでください。したがって、キャッシュの動作はますます重要になります。適切なキャッシュ動作を実現する最善の方法は、データセットを小さくすることです。したがって、4 バイトと 16 バイトの間の一見無関係な違いが、速度に顕著な違いをもたらす可能性があります。必ずしも常にではありませんが、考慮する必要があります。

score 8 · Accepted Answer

主キーと外部キーの関係などの値を比較する場合、INT の方が高速になります。テーブルが適切にインデックス化されていて、テーブルが小さい場合、速度低下はあまり見られないかもしれませんが、確認するために試してみる必要があります。INTは読みやすく、他の人とのコミュニケーションも容易です。「レコード 1234 を見てもらえますか?」と言う方がはるかに簡単です。「レコード 031E9502-E283-4F87-9049-CE0E5C76B658 をご覧いただけますか?」の代わりに

score 6 · Accepted Answer

ある段階でデータベースのマージを計画している場合、つまりマルチサイトレプリケーションタイプのセットアップを計画している場合、Guid を使用すると多くの手間が省けます。しかし、それ以外は Int の方が簡単だと思います。

score 5 · Accepted Answer

データが単一のデータベースに存在する場合 (一般的に作成するアプリケーションのほとんどのデータがそうであるように) IDENTITY、. 簡単で、そのように使用することを意図しており、クラスター化されたインデックスを断片化せず、十分すぎるほどです。20 億個のレコード (負の値を使用する場合は ~ 40 億個) でスペースが不足しますが、1 つのテーブルにそれだけ多くのレコードがあり、データウェアハウジングの問題が発生した場合は、いずれにせよ乾杯します。

データが複数の独立したデータベースまたはサードパーティサービスとのインターフェイスに存在する場合は、GUIDおそらく既に生成されているものを使用します。objectGUID良い例は、Active Directory 内のユーザーを、割り当てられた Active Directoryを介してアプリケーション内のユーザープロファイルにマップする、データベース内の UserProfiles テーブルです。

score 4 · Accepted Answer

一部の OS では、固有のハードウェア機能 (CPUID、MAC) に基づいて GUID を生成しなくなりました。これは、ユーザーの追跡を容易にするためです (プライバシー上の懸念)。これは、GUID の一意性が、多くの人が考えるほど普遍的ではないことが多いことを意味します。

データベースの自動 ID 機能を使用すると、データベースは理論上、重複がないことを完全に確認できます。

score 2 · Accepted Answer

私はいつも、PK は可能な限り数値であるべきだと考えています。GUID を PK として持つことは、他のテーブルでも外部キーとして使用されることを意味することを忘れないでください。そのため、ページングやインデックスなどが大きくなります。

score 1 · Accepted Answer

データベースも重要だと思います。MySQL の観点からは、一般に、データ型が小さいほどパフォーマンスが向上します。

int vs GUID にも当てはまるようです - http://kccoder.com/mysql/uuid-vs-int-insert-performance/

score 1 · Accepted Answer

このキーが同様の値にバインドされている場合にのみ、GUID を PK として使用します。たとえば、ユーザー ID (WinNT のユーザーは GUID で表されます)、またはユーザーグループ ID です。もう一例。ドキュメント管理用の分散システムを開発し、システムのさまざまな部分を世界中のさまざまな場所で開発すると、いくつかのドキュメントを作成できます。このような場合、分散システムの異なる部分で作成された 2 つのドキュメントが同じ ID を持たないことが保証されるため、GUID を使用します。

score 0 · Accepted Answer

INT は確かに、デバッグ時にはるかに読みやすく、はるかに小さくなっています。

ただし、製品のライセンスキーとして GUID などを使用します。一意になることはわかっていますが、連続するわけではないこともわかっています。

database - GUID と INT IDENTITY

13 に答える 13

Related

Reference