SQL服務器引用的外鍵非主鍵列

最近我們遇到的情況如下：SQL服務器引用的外鍵非主鍵列

我們正在設計一個數據庫和預測數據將在6個月內顯著增長到數百萬的記錄。我們希望每一行都應該有一個Guid作爲唯一ID，它允許我們稍後將數據移動到OLAP/Archive數據庫，在Identity和Guid鍵的許多參數之後，我們提出了Guid作爲唯一ID。但是，Guid作爲主鍵總是一個壞主意，因此我們有表的主鍵是一個標識列。設計看起來像下面

用戶：

| Id (PK, Identity)             | 
| UserId (Guid, Unique-constraint, non-clustered index)    | 
| Name                | 
| Email                | 
| ...                |

注意：

| Id (PK, Identity)             | 
| NoteId (Guid, Unique-constraint, non-clustered index)    | 
| UserId (Guid, Foreign Key to Users(UserId)      | 
| Title                | 
| Text                | 
| ...                |

如果將數據移動到存檔我們並不需要關心的身份密鑰了。

這個設計有什麼問題嗎？表現如何？請給我建議，謝謝。

來源

2013-05-21 Khoa Nguyen

這應該沒問題。如果外鍵引用Users.Id，性能可能會更好（並且您始終可以將其轉換爲對存檔中的Users.UserId的引用），但這並不重要。 – Serge

即使您沒有將GUID作爲主鍵，您仍然會將其用於連接，從而爲服務器做更多工作。

是否有你不使用Users.Id作爲FK目標的原因？

UserId (INT, Foreign Key to Users(Id)

記住，你也將會是想要索引上面列，所以你的方式，你仍與上表中的兩個GUID索引，可能支離破碎，我敢打賭，程序員在做隨機的GUID結束應用層，而不是在數據庫中製作NEWSEQUENTIALID（）？

來源

2013-05-21 08:50:55 Meff

沒有引用用戶（Id）的原因是，我之前經歷過一次身份驗證密鑰在與MySQL的複製中移動，現在真的害怕這種情況，修復數據是一場噩夢。通過MS SQL服務器，我們在最近的一個項目中再次發生了重大轉變，幸運的是我們很早就發現了它。 Guid可以在Databse服務器或業務層提供，我們還沒有決定。 –

@KaneNguyen如果你想知道如何製作GUID，請查看NEWSEQUENTIALID（http://technet.microsoft.com/en-us/library/ms189786.aspx），它從2005年開始，真正減少了GUID索引碎片化 - 這會緩解一些問題。我會對如何發生重大轉變感興趣 - 我從來沒有見過它。 – Meff

AFAIK，NEWSEQUENTIALID將在重新啓動服務器後在不同的段上重新啓動。沒有保證，新的細分市場將落後於前一個，但我同意它會給予更好的性能比NEWID –

SQL服務器引用的外鍵非主鍵列

回答

相關問題