查詢表上的SQL主鍵或唯一約束？

Question

我想創建一個查詢表“ orderstatus”。 即下面，只是為了澄清這一點將在數據倉庫中使用。 如果需要，我將需要通過OrderStatus加入以檢索INT（如果我創建一個）以在其他地方使用。 例如，在事實表中，我會將int存儲在事實表中以鏈接到查找表。

+------------------------+------------------+
| OrderStatus            | ConnectionStatus |
+------------------------+------------------+
| CLOSED                 | APPROVE          |
+------------------------+------------------+
| COMPLETED              | APPROVE          |
+------------------------+------------------+
| FULFILLED              | APPROVE          |
+------------------------+------------------+
| CANCELLED              | CLOSED           |
+------------------------+------------------+
| DECLINED               | CLOSED           |
+------------------------+------------------+
| AVS_CHECK_SYSTEM_ERROR | CLOSED           |
+------------------------+------------------+

關於主鍵/唯一鍵的最佳實踐是什么？ 我應該只創建一個具有身份的OrderStatusKey INT作為PrimaryKey嗎？ 還是對訂單狀態創建唯一約束（唯一）？ 謝謝。

Answer 1

為此，我建議您創建一個Identity列，並使其成為群集的主鍵。

表具有某種主鍵被認為是最佳實踐，但是像這樣的表具有聚集索引是允許在多表查詢（帶有joins）中使用該表的最快方法。

以下是有關如何添加的示例：

ALTER TABLE dbo.orderstatus 
ADD CONSTRAINT PK_orderstatus_OrderStatusID PRIMARY KEY CLUSTERED (OrderStatusID);
GO

文章更多的細節MSDN

這里是說明一個主鍵的另一個資源主鍵底漆

Answer 2

如果OrderStatus是唯一的並且是主要標識符AND，那么您將直接在相關表中重用此狀態代碼（而不是指向此狀態代碼的數字指針），則將這些列保持原樣，並使OrderStatus成為主要的聚集索引。

一點解釋：

主鍵在整個表中是唯一的； 聚集索引將所有記錄數據綁定回該索引。 主鍵也不一定總是表上的聚簇索引，但通常是這種情況。

---

如果要使用狀態代碼以外的其他內容鏈接到訂單狀態，請創建另一個類型為int列作為IDENTITY並使其成為主集群鍵。 還要向OrderStatus添加唯一的非聚集索引，以確保不會添加任何重復項。

---

無論采用哪種方式，每個表都應具有主鍵以及聚集索引（同樣，通常它們是相同的索引）。

Answer 3

這里有一些要考慮的事情：

• PRIMARY KEY確保表中沒有NULL值或重復項
• UNIQUE KEY可以包含NULL並且（按ANSI標准）可以包含任意數量的NULL 。 （此行為取決於SQL Server設置和可能的索引篩選器-不是空約束）
• CLUSTERED INDEX包含與葉子上的一行相關的所有數據。
  • 當CLUSTERED INDEX不唯一（並且不為null）時，SQL Server將向每行添加一個隱藏的GUID 。
  • 當鍵列不是唯一的以區分各個記錄時，SQL Server將隱藏的GUID列添加到鍵列列表中
• 所有索引都使用聚集索引的鍵列值或堆表的rowid。
• 查詢優化器使用索引統計信息來找出執行查詢的最佳方法
• 對於小型表，通常會忽略索引，因為進行索引掃描后，對每個值的查找比進行全表掃描（在擁有非常小的表的情況下將讀取一頁或兩頁）的開銷更大。
• 狀態查詢表通常很小，可以存儲在一頁上。

引用表將在其結構中存儲PK值（或唯一）（這也是您用來進行聯接的內容）。 如果您有一個整數鍵用作參考（SQL Server中又稱為IDENTITY），則對性能會有一點好處。

如果您通常不想列出ConnectionStatus ，那么使用實際的顯示值（ OrderStatus ）可能會有所幫助，因為您不必加入查找表。

您可以將兩個值都存儲在引用表中，但是維護這兩個列都會有一些開銷，並且會出現更多錯誤空間。

群集/非群集問題取決於此表的用例。 如果通常使用OrderStatus進行過濾（使用文本形式），則OrderStatu上的NON CLUSTERED IDENTITY PK CLUESTERED UNIQUE NON CLUSTERED IDENTITY PK和CLUESTERED UNIQUE可能會有所幫助。 但是（如您在上面閱讀的），在小表中效果/性能增益通常可以忽略不計。

如果您不熟悉上述情況，並且覺得比較安全，請在OrderStatus上創建一個標識聚類的PK（ OrderKey或OrderID ）和一個唯一的非聚類的密鑰。

使用PK作為外鍵中的引用/引用列。

還有一件事：如果僅一個表將引用此列，則您可能要考慮創建一個包含兩個表的數據的索引視圖。

另外，我建議添加一個虛擬值，如果未設置狀態，則可以使用該值（並將其用作所有引用列的默認值）。 因為未設置仍然是狀態，不是嗎？