我們從舊訂購系統遷移了大量數據。該系統將用戶的首字母縮寫存儲在我們的「訂單」表中，用於他們創建的每個訂單。現在我們有了一個查看活動目錄的視圖，我想用活動目錄objectguid（或引用guid的東西）更新這些首字母縮寫。這將允許我們更改活動目錄中的用戶首字母，而不必擔心更新「訂單」表記錄。SQL Server GUID（來自Active Directory）vs Int
我讀過使用guids vs ints時索引性能低下的問題。解決這個問題的方法之一是有一個表格，將guid映射爲整數，然後將int值存儲在我們的訂單表中。這是個好主意嗎？有什麼想法嗎？
我假設一個用戶實體已經存在於您的數據庫設計中，但是，如果它不存在，那麼我相信您的解決方案將需要它。
所以假設USER實體存在，正如你所描述的那樣，你可以將用戶ID（INT）在訂單表，從而一切有關USER細節的ORDER，而不僅僅是縮寫（注意：縮寫應該說是不被存儲在ORDER表而是USER或USER_DETAILS表，儘管該討論的不是重點）。
然後，您可以將GUID列添加到USER表。我不認爲一個單獨的查找表是必要的。
有意義嗎？
GUID的索引性能與16字節字段上的其他索引通常沒有區別。在GUID對性能致命的情況下，當您在SQL Server表上使用它們作爲集羣密鑰時。
SQL Server表是聚集鍵和物理由該鍵進行排序。由於GUID本質上是完全隨機的，因此這會導致很快的大量索引碎片化，因此需要a）持續的進料和維護和重組，但b）即使每晚都進行重組仍然會受到影響。所以最好的做法是避免GUID（即使是新的「順序」GUID）。
欲瞭解更多背景資料和爲什麼的GUID使很差聚集鍵一些優秀的評論，看到金佰利特里普的「索引女王」的博客：
她的觀點是最寶貴的 - 讀它，它內在化，遵循它！你不會後悔的。
Marc
如何使映射表比使用guid作爲表中的字段更好，但不是集羣密鑰？ – 2009-07-03 21:06:32
我的思考過程是映射表將有大約100行，可以快速查找int，並且如果使用索引ints而不是索引uniqueidentifiers的性能優勢，那將是值得的，因爲我們的orders表有超過400萬行。請讓我知道，如果我的思維方式是完全脫離基地:) – 2009-07-03 21:12:29