簡單主鍵與復合主鍵的優缺點
我正在嘗試為數據庫建模。對於問題的一部分，我有一個實體區域，其中包含部門，並且每個部門都分配了特定的功能。我有以下。
我想了兩種處理關係的方法。第一種是為 Department 表創建一個自增鍵，假設部門名稱可以在不同區域重複。我對 Function 表執行相同操作，將可遞增鍵作為標識符，並為組合（Department_ID、Name）創建一個唯一鍵。
第二種方式是把欄位組合（Department_ID, Name）作為Department的主複合鍵，Function表也一樣，把欄位（Department_ID, Name）作為複合主鍵。
與第一種情況一樣，使用簡單鍵而不是複合鍵有哪些優點或缺點，它如何影響唯一鍵的使用？這是正確的方法嗎？
簡短的回答
從邏輯的角度來看，複合鍵沒有固有的缺點。它存在。如果需要保持唯一性/數據完整性，則必須使用它。
從物理實現的角度來看，複合鍵可能會創建 b 樹和聚集索引（如果使用/支持）的碎片，因為插入不能保證附加到表的末尾。大多數商業數據庫引擎在處理/管理碎片方面都非常出色（有些總是將新行附加到新頁面），因此這不應該是您選擇一個而不是另一個的理由，除非在非常有限的情況下。
更長的答案
所以讓我們回顧一下，因為我認為大多數從業者都忽略了關於主鍵的一個關鍵問題：
主鍵必須強制數據的唯一性。
id列不強制唯一性，因為它是系統生成的，而不是從數據中生成的。因此，在數據建模開始時對每個實體都添加一個是沒有意義的，
id因為它會妨礙您理解數據的實際結構。id一旦知道實際的鍵，我們就可以稍後應用列。將id成為先前主鍵的代理項，該鍵將成為備用鍵。因此，我可以從您的圖表中看到，您至少知道後來的事實
Function，但沒有將其應用於AreaorDepartment。因此，讓我們首先從等式中刪除行標識符。這就是你所擁有的：
這時候自然會問：
- 是
function獨立於一切的departments嗎？- 一個以上可以
department實現相同function嗎？在第一種情況下，我們的模型將變為：
但如果第二個成立，那麼模型將是：
所以你可以看到，在我們開始考慮是否用代理項替換現有的主鍵之前，還有很多工作要做。
我們可能會認為
Area_Name它太寬而無法在實踐中使用。我們可以將其作為備用鍵並替換為人類可讀的程式碼/短名稱（首選）或系統生成的整數（如果您確實必須）。我們可以類似地決定Department_Name.所以讓我們實現第二個模型，用代理替換寬鍵：
在這種情況下，
DepartmentFunction鍵(Department_Id,Function_Id)是：
- 袖珍的
- 保留與 的關係
Department，稍後在數據模型中可能需要該關係以實現完整性所以沒有令人信服的理由來取代它。
我要強調的一件事是，僅使用整數代理作為最後的手段。如果有可以使用的速記/程式碼，則最好是：
- 它是人類可讀的
- 可能已經普遍使用
- 可能會減少所需的連接數
- 如果長度小於 4 可能會更緊湊
- 減少數據錯誤（整數列被交換的次數超過了一些人願意承認的次數）
