SQL Server GUID (Active Directory から) と Int の比較

Question

古い注文システムから多くのデータを移行しました。このシステムは、作成した注文ごとにユーザーのイニシャルを「注文」テーブルに保存しました。Active Directory を参照するビューができたので、これらのイニシャルを Active Directory の objectguid (または guid を参照するもの) で更新したいと思います。これにより、「Orders」テーブルのレコードの更新を気にせずに、Active Directory 内のユーザーのイニシャルを変更できるようになります。

guid と int を使用した場合、インデックスのパフォーマンスが低下するという記事を読みました。これを解決する 1 つの方法は、guid を int にマップするテーブルを用意し、その int 値を order テーブルに格納することです。これは良いアイデアでしょうか?何かご意見は？

Answer 1

私は、 ユーザー エンティティはデータベース設計にすでに存在しますが、存在しない場合は、ソリューションでそれが必要になると思います。

したがって、 ユーザー エンティティが存在する場合、説明したように、UserID(int) を 注文 テーブルを作成し、関連するすべてのデータを関連付けます。 ユーザー 詳細は 注文, 単なるイニシャルではなく、おそらくイニシャルは保存すべきではありません。 注文 テーブルではなく、 ユーザー または ユーザーの詳細 この議論の焦点では​​ありませんが、表に記載されています)。

その後、GUID 列を USER テーブルに追加できます。別のルックアップテーブルは必要ないと思います。

意味をなす？

Answer 2

GUID のインデックスのパフォーマンスは、通常、16 バイト フィールドの他のインデックスと変わりません。GUID がパフォーマンスにとって致命的なのは、GUID を次のように使用する場合です。 クラスタリングキー SQL Server テーブル上。

SQL Server テーブル は クラスター化されたキーであり、そのキーによって物理的に順序付けされます。GUID は本質的に完全にランダムであるため、これによりすぐに大規模なインデックスの断片化が発生し、a) 継続的なフィード、ケア、再編成が必要になりますが、b) 毎晩再編成したとしても依然として問題が発生します。したがって、実際のベスト プラクティスは、クラスタリング キーの GUID (新しい「連続」GUID であっても) を避けることです。

GUID が非常に貧弱なクラスター化キーを作成する理由の詳細な背景情報といくつかの優れた記事については、「インデックス作成の女王」である Kimberly Tripp のブログを参照してください。

• 主キーとしての GUID
• クラスター化インデックスの議論は続いています...
• クラスター化インデックスの議論....再び!

彼女の洞察力は最も価値があります。読んで、理解して、従ってください。後悔することはありません。

マルク