對主鍵使用現有的候選鍵或新的組合鍵

我從不同的數據源收到一些可能成爲我數據庫的候選鍵的唯一個案號。當創建一張全新的桌子時，最佳做法是什麼？創建一個組合鍵（我的候選鍵和PK的自動生成ID），或者只是爲這個新表定義一個PK，並且在候選鍵上定義一個CHECK CONSTRAINT？對主鍵使用現有的候選鍵或新的組合鍵

來源

2017-09-15 Nima M.

答案是* depends *。但我真的沒有看到爲自動遞增的ID和唯一的案例編號創建組合鍵的理由。特別是如果你有'1，123'，'5,123'（id，case_number），你的唯一的案例號不再那麼獨特。除非您通過限制或檢查的存儲過程從輸入運行有效性檢查。如果是這種情況，那麼你不妨使用自動增量ID。 – Simon

-1

最好的做法是你的DB擁有所有者PK。考慮這種情況，您的來源是Sales Force的產品表格，產品代碼爲'1234'，出於任何原因，您的公司在一段時間後更改SAP並將相同產品的代碼更改爲'KA2541'。如果您使用的銷售隊伍代碼PK建模您的數據庫，你有兩個選擇：

創建一個新的列，以保存新的代碼，並改變所有的程序，以顯示新的代碼
變化的數據類型列並更新它。

這兩種情況有很多風險關聯，另一方面，如果你開始你的建模考慮一個列到外部鍵無關緊要你更新外部代碼時源更改。

來源

2017-09-15 18:17:44

這是一個棘手的問題。一般來說，我習慣於推薦代理主鍵 - 但不是組合鍵，只是自動增加的鍵。以下是一些原因：

整數主鍵較小，所以它們佔用較少的空間。
整數外鍵的大小是統一的，因此往往更有效率（小考慮）。
源系統可能會更改密鑰的定義。

也就是說，有些情況下您可能想使用源系統密鑰而不是人爲密鑰。假設代碼真的屬於源系統，並且不會改變（源系統定義了「它」是什麼）。然後，您可能希望將其作爲主鍵 - 如果有可能需要重新加載數據。

爲什麼？數據重新加載可能會重新排序鍵。外鍵引用將會失效。通常情況下，數據重新加載將使用更新進行處理，但可能會出現需要進行批發替換的情況。

你可以想象我最近遇到了這樣的情況。

來源

2017-09-15 18:27:26

「棘手的問題」是正確的表達！沒有普遍接受的最佳做法。有些人使用GUID作爲主鍵，有些人使用身份列（aka序列，數字範圍），有些人更喜歡基於商業密鑰列的md5（或sha ...）哈希的哈希鍵（啓用並行加載），有些人只是使用商業密鑰（可選化合物如植物+材料編號）。有時，您將所有或部分混合在一個系統中（如SAP ERP系統）。最佳實踐是在大多數情況下是宗教問題，而不是基於某些證據。 –

@ChristophG。。。完全沒有。對於主鍵也用作聚集索引的數據庫中的主鍵，GUID是一個不錯的選擇。它在插入時導致不必要的頁面拆分。 –

對主鍵使用現有的候選鍵或新的組合鍵

回答

相關問題