SQL Server：主鍵架構具有很大的指導性，但有時是整數類型

Question

好的，這可能是一個愚蠢的問題，但是...

我繼承了一個項目，並負責遍歷主鍵關系。

該項目主要使用Guids。 我之所以說“很大”，是因為在某些示例中，表使用整數類型來反映枚舉。 例如，dbo.MessageFolder具有類型為int的MessageFolderId來反映

public emum MessageFolderTypes
{
  inbox = 1,
  sent = 2, 
  trash = 3, 
  etc...
}

這經常發生。 有一些主鍵類型為int的表是不可避免的，因為它們依賴於枚舉，而有些表的主鍵類型為Guid，它們反映了以前程序員的主鍵選擇。

我是否應該擔心PK模式如此參差不齊？ 感覺不對，但這真的重要嗎？ 如果這會造成問題，我該如何解決（如果沒有認真的工作，我真的無法將所有PK都移動到int類型，而且我從未聽說過具有Guid值的枚舉）？

謝謝。

Answer 1

理想情況下，由於性能原因，您最好從GUID移開作為PK-但我知道這可能是不可能的。

GUID的性能在這里很好地列出： 與標准Guid相比，Sequential Guid在性能上有哪些改進？

我不會擔心斑點，如果您使用最小的密鑰，那么您必然會在數據庫中將幾種不同的數據類型作為PK（TinyInt / SmallInt / Int / BigInt）使用。

Answer 2

您可以為“快速獲勝”做些什么：

• 保留主鍵不變（好處：您不需要更改參照完整性約束）
• 但是將您的GUID主鍵設置為非集群主鍵
• 將聚類密鑰放在單獨的字段上-使用已有的東西，如果有有用的字段-否則，使用INT IDENTITY字段

擁有良好的集群密鑰可以帶來顯着的性能提升！ 不只是幾個百分點-幾個數量級。

在這里閱讀為什么將GUID作為主鍵 （實際上：作為聚簇鍵）是一個糟糕的選擇，並在這里閱讀The Clustered Index Debate-Again！ 好的集群鍵應該是什么樣子-理想情況下：

• 窄（盡可能少的字節）
• 靜態的（永遠不變）
• 唯一的（否則，SQL Server將需要通過向其添加4個字節來“唯一化”您的條目）
• 不斷增加（避免昂貴的頁面拆分並減少索引/頁面碎片）

廉潔是一個理想的人選。

Answer 3

最重要的是，必須執行確保完整性所需的所有密鑰。 沒有真正的理由為什么必須在每個表中將相同類型的列用作鍵。 大概您還有其他（自然）鍵也由唯一約束/索引強制執行，如果是這樣，我希望其中一些包含不是整數也不是guid的列。