自然鍵與代理鍵
身為資料庫設計人員，你將面臨的首要決定是你的資料表應使用哪種主索引鍵（PK）。如果你詢問任何每天都要處理資料庫的人，無論是資料庫管理員、開發人員還是測試人員，你都會得到無數的意見和理由。使解決問題的障礙更為複雜的是，沒有一種萬能的方案。有鑑於此，本系列將介紹支持和反對不同類型 PK 的一些原因。在所有這些原因的某處，將會引導你找出 PK 的最佳類型，以滿足你的組織需求。在第一部分中，我們將比較兩種基本類型的 PK：自然鍵和代理鍵。稍後，我們將討論是否使用資料庫自動遞增功能，以及哪些資料類型（如果有）是最好的 PK。
自然鍵
自然鍵是由資料表中已存在的一個或多個欄組成的（例如，它們是資料模型中實體的屬性），用於唯一標識資料表中的一筆記錄。由於這些欄是實體的屬性，因此它們本質上具有業務意義。以下是 Navicat Premium 16 的資料表設計器中有自然鍵的資料表範例。我們可以透過 「鍵」欄中的鑰匙圖示輕鬆找到主索引鍵：
查看一下資料，我們可以知道 productCode 是有業務意義的：
代理鍵
代理鍵（或合成鍵、虛擬鍵、實體識別碼、非事實型鍵、技術鍵等！）是由系統產生的（GUID、序列、唯一識別碼等）值，沒有業務意義 ，用於唯一標識資料表中的記錄。鍵本身也可以由一欄或多欄（即復合鍵）組成。我們可以看到在同一個資料庫的資料表中有一個代理鍵，定義了一個 customerNumber 欄作為資料表的 PK：
雖然該欄不是自動遞增，但它是一個與客戶實體無關的數字欄位：
作出決定
那麼，為什麼一個資料表使用自然鍵，而另一個資料表使用代理鍵呢？
產品有一個唯一的庫存編號是很常見的，這是一個理想的PK。而加入一個額外的數字鍵只會浪費磁碟空間，並且幾乎肯定需要在 productCode 欄上加入一個用於搜尋的額外索引。但另一方面，客戶通常不會有一個唯一的識別碼。若你必須在資料庫中辨識特定客戶，可能需要一個長得驚人的欄清單。因此，指派一個數字代理鍵來索引資料表中每一欄通常要容易得多。
自然鍵與代理鍵的總結
在「選擇主索引鍵」的第一部分中，我們探討了自然主索引鍵和代理主索引鍵，並考慮了什麼因素決定選擇哪一種。決定一開始使用自然鍵還是代理鍵是很重要的，因為你選擇哪種主索引鍵也將有助於解答一些後續問題，特別是使用代理鍵。
如果你想試用 Navicat 16，你可以在這裡下載 14 天試用版。
