古い注文システムから多くのデータを移行しました。このシステムは、ユーザーが作成した注文ごとに、ユーザーのイニシャルを「注文」テーブルに保存しました。Active Directory を表示するビューができたので、これらのイニシャルを Active Directory objectguid (または GUID を参照するもの) で更新したいと思います。これにより、"Orders" テーブル レコードの更新を気にせずに、Active Directory でユーザーのイニシャルを変更できます。
GUIDとINTを使用すると、インデックスのパフォーマンスが低下することを読みました。これを解決する 1 つの方法は、guid を int にマップするテーブルを作成し、int 値を orders テーブルに格納することです。これは良い考えでしょうか？何かご意見は？
データベース設計にUSERエンティティが既に存在すると仮定しますが、そうでない場合は、ソリューションでそれが必要になると思います。
したがって、説明したようにUSERエンティティが存在すると仮定すると、 UserID(int) をORDERSテーブルに配置して、関連するすべてのUSER詳細をイニシャルだけでなくORDERに関連付けることができます(注: イニシャルは間違いなく、この説明の焦点ではありませんが、ORDERテーブルではなく、USERまたはUSER_DETAILSテーブルです)。
その後、GUID 列を USER テーブルに追加できます。別のルックアップ テーブルは必要ないと思います。
わかる？
一般に、GUID のインデックス パフォーマンスは、16 バイト フィールドの他のインデックスと変わりません。GUID がパフォーマンスにとって致命的なのは、それらをSQL Server テーブルのクラスタリング キーとして使用する場合です。
SQL Server テーブルはクラスター化されたキーであり、そのキーによって物理的に順序付けられます。GUID は本質的に完全にランダムであるため、これは非常に迅速に大規模なインデックスの断片化につながり、a) 絶え間ないフィードとケアと再編成が必要になりますが、b) 毎晩再編成しても問題は解決しません。実際には、ベスト プラクティスは、クラスタリング キーの GUID (新しい「シーケンシャル」GUID であっても) を避けることです。
詳細な背景情報と、GUID がクラスター化されたキーを非常に貧弱にする理由に関するいくつかの優れた記事については、「インデックス作成の女王」である Kimberly Tripp のブログを参照してください。
彼女の洞察は最も価値があります - それを読み、それを吸収し、それに従ってください! 後悔することはありません。
マルク