GUID vs INT IDENTITY [複製]
https://stackoverflow.com/questions/829284
-
06-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian質問
可能な重複：
主キーはどうですか？
GUIDを使用する利点と、データベースでPKとしてINTを使用することの利点を認識しています。 GUIDは本質的に128ビットINTであり、通常のINTは32ビットであると考えると、INTはスペース節約になります（この点は一般的にほとんどの最新システムでは意味がありません）。
最後に、どのような状況でINTをPK対GUIDとして使用していると思いますか？
解決
Kimberley Tripp（SQLSkills.com）には GUIDを主キーとして使用する記事。不必要なオーバーヘッドのため、彼女はそれに対してアドバイスします。
他のヒント
複数のデータベースインスタンスを同期する必要がある場合の不適切な選択とは別に、INTには、言及されていない1つの欠点があります。挿入は常にインデックスツリーの一端で発生します。これにより、同じインデックスページを同時挿入で変更する必要がありますが、GUIDはインデックス全体に挿入されるため、多くの移動があるテーブルがある場合、ロックの競合が増加します。 B *ツリーまたは同様のデータ構造が使用されている場合、インデックスはより頻繁に再調整する必要があります。
もちろん、手動のクエリやレポートの作成を行う場合、intのほうが目に見えやすく、FKの使用によってスペースの消費が増える可能性があります。
どの程度の測定値が見たいですか？ SQL Serverは、実際にはIDENTITY PKで挿入が多いテーブルを処理します。
質問に答えるには： 最後に、どのような状況でINTをPK対GUIDとして使用していると思いますか？
システムにオンライン/オフラインバージョンがあり、オフラインバージョン内でデータを保存でき、同期中にそのデータがサーバーに転送される場合、GUIDを使用します。そうすれば、データベース内で同じキーを2回使用することはありません。
INTはスペースセーバーです（ただし、 ほとんどの現代では、ポイントは一般的に意味がありません システム）。
そうではありません。一見そう見えるかもしれませんが、各テーブルのプライマリキーは、インデックス内のデータベース全体および他のテーブルの外部キーとして複数回繰り返されることに注意してください。また、そのテーブルを含むほぼすべてのクエリに関与します。結合に使用される外部キーの場合は非常に集中的になります。
さらに、最新のCPUは非常に高速ですが、RAMの速度は維持されていません。したがって、キャッシュの動作はますます重要になります。また、適切なキャッシュ動作を実現する最良の方法は、データセットを小さくすることです。したがって、4バイトと16バイトの間の見かけ上は無関係な違いは、顕著な速度の違いをもたらす可能性があります。必ずしも常にではありません-しかし、それは考慮すべきものです。
非常に複雑なエンタープライズソフトウェアには、あらゆる場所にGuidがあります。スムーズに動作します。
Guidは識別子として機能するのに意味的に適していると思います。また、その問題に直面するまでパフォーマンスを不必要に心配しても意味がありません。時期尚早な最適化に注意してください。
あらゆる種類のデータベース移行にも利点があります。 Guidsを使用すると、衝突は発生しません。 intが識別に使用される複数のDBをマージしようとする場合、それらの値を置き換える必要があります。これらの古い値がURLで使用されていた場合、SEOヒット後に異なる値になります。
プライマリキーと外部キーの関係などの値を比較する場合、INTの方が高速です。テーブルのインデックスが適切に作成され、テーブルが小さい場合、速度の低下はあまり見られないかもしれませんが、確実に試してみる必要があります。また、INTは読みやすく、他の人と通信しやすくなっています。 「レコード1234を確認できますか？」と言う方がはるかに簡単です。 「＆quot;レコード031E9502-E283-4F87-9049-CE0E5C76B658を見ることができますか？」の代わりに
一部のOSでは、ユーザーの追跡が容易になったため（プライバシーの問題）、独自のハードウェア機能（CPUID、MAC）に基づいてGUIDを生成しなくなりました。これは、GUIDの一意性が多くの人が考えるほど普遍的ではなくなることが多いことを意味します。
データベースのauto-id関数を使用する場合、データベースは理論上、重複がないことを絶対的に確認できます。
データが単一のデータベースに存在する場合（一般に記述するアプリケーションのほとんどのデータがそうであるように）、 IDENTITY を使用します。簡単に使用でき、そのように使用することを意図しており、クラスター化インデックスを断片化せず、十分すぎるほどです。一部のレコードは20億個（負の値を使用する場合は40億個）になりますが、1つのテーブルにそのようなレコードがあり、データウェアハウジングの問題がある場合は、とにかく乾杯します。
データが複数の独立したデータベースに存在する場合、またはサードパーティサービスとのインターフェイスがある場合は、おそらく既に生成されている GUID を使用します。良い例は、Active Directoryに割り当てられた objectGUID を介して、Active DirectoryのユーザーをアプリケーションのユーザープロファイルにマッピングするデータベースのUserProfilesテーブルです。
ある段階でデータベースのマージを計画している場合、つまり、マルチサイトレプリケーションタイプのセットアップの場合、Guidを使用すると多くの苦痛が軽減されます。しかし、それ以外はIntの方が簡単だと思います。
PKは可能な限り数値である必要があります。 GUIDをPKとして使用することは、おそらく他のテーブルで外部キーとしても使用されることを意味するので、ページングやインデックスなどが大きくなることを忘れないでください。
データベースも重要だと思います。 MySQLの観点から-一般的に、データ型が小さいほどパフォーマンスが速くなります。
int vs GUIDにも当てはまるようです- http://kccoder.com/mysql/uuid-vs-int-insert -performance /
このキーが同様の値にバインドされている場合にのみ、GUIDをPKとして使用します。たとえば、ユーザーID（WinNTのユーザーはGUIDで記述されます）、またはユーザーグループIDです。 別の例。文書管理用の分散システムを開発し、世界中のさまざまな場所にあるシステムのさまざまな部分でいくつかの文書を作成できます。そのような場合、GUIDを使用します。これは、分散システムの異なる部分で作成された2つのドキュメントが同じIDを持たないことを保証するためです。
INTは確かにデバッグ時にずっと読みやすく、ずっと小さくなります。
ただし、製品のライセンスキーとしてGUIDなどを使用します。あなたはそれがユニークになるだろうことを知っています、そしてそれはシーケンシャルにならないことを知っています。
