SQL Server中PK的最佳實踐

Question

我一直想知道在SQL Server中的M2M表中設置PK的最佳實踐或后果是什么。 例如：

我有2張桌子

• 用戶
• 角色

我正在制作一張新桌子

• UserRole的

其中有2個字段RoleId和UserID

我現在應該

1. 創建一個UserRoleID作為PK，並使UserID和RoleID成為FK
   • 制作PK UserID和RoleID並將它們設置為FK
   • 別的

我想知道每個選項的性能問題以及推薦的最佳實踐。

Answer 1

這些案例的標准程序是有兩個索引。 唯一的PK是兩個字段復合，首先是具有更大基數的字段，即UserID; 和第二個索引只有輔助字段（即RoleID）。

然后聚集在更多多記錄結果集中可能涉及的任何一個（即，如果查詢每個用戶的多個角色，或每個角色多個用戶）。

Answer 2

將PK聲明為（UserID，RoleID）。 （注意：順序很重要）

使用對Users表的引用將UserID聲明為FK。 將RoleID聲明為FK，並引用Roles表。

運氣好的話，您的DBMS將按順序為您提供（UserID，RoleID）的綜合索引。

運氣好的話，這將加速用戶和角色之間的聯接。 一個好的DBMS將為連接提供合並連接，除了連接條件之外沒有任何限制。 假設角色數量很少，三向連接也應該運行得非常快。

當您加入UserRoles和Roles時，如果沒有加入用戶，您可能會發現它的速度令人失望。 你經常這樣做，在這種情況下速度有多重要？ 如果它很重要，您可以僅在RoleID上創建索引。

Answer 3

這取決於您是否希望將特定用戶具有特定角色的任何其他含義掛起。 如果沒有，那么只需創建一個跨越兩個字段的聚簇PK。

為兩者添加FK並向第二個字段添加索引。 考慮字段應該出現在哪個順序。您是否更有可能檢索用戶所屬的角色集或特定角色的用戶集？

Answer 4

這取決於你如何使用它們。 大多數時候，我將主鍵作為UserId和RoleId來確保它們是唯一的。 意味着同一個用戶不能擁有相同的角色。

現在這就是“依賴”發揮作用的地方。 如果要將UserRole表鏈接到另一個表，那就是我創建UserRoleId主鍵的位置。 並將UserId和RoleId變為唯一約束。

這樣做的原因是在引用UserRole的表上沒有不需要UserId和RoleId的表，因為您分別鏈接到UserRoleId而不是User表和角色表。

Answer 5

避免使用復合PK並在兩個FK上放置一個唯一索引（在本例中似乎是合適的）。 在這種情況下不是問題，但要保持一致。 在編寫查詢時必須記住要處理要加入的多個字段是一件痛苦的事。 如果您的復合鍵必須由datetime，char或其他類型的字段組成，則性能會受到影響。