使用我的客戶程式碼作為主鍵有什麼優點和缺點？
我正在為我的一個銷售團隊設計一個數據庫。目前，目標是獲取客戶及其郵寄地址的主列表，但數據庫最終將擴展以跟踪其他一些客戶數據。所以，現在我只是在處理客戶表，但想確保我遵循良好的規範化和效率準則，以防這件事超出目前的預期。
目前，我們有大約 3,000 名客戶。因此，我們有用於辨識客戶的客戶程式碼。每個最多可以有 20 個字元，是字母數字，並且每個客戶始終是唯一的（Foo, Inc. 可能有 FOOINC 的客戶程式碼，可能有 25 個子帳戶，但只有一個 FOOINC 主實體。如果我們曾經與另一家名為 Foo Technologies Inc 的公司合作過，我們會創建一個新程式碼，例如 FOOTECH 或其他東西）。
我不是 DBA，但過去設計了幾個 DB，並且傳統上使用 SQL 標識欄位作為 PK。在這種情況下，我一直在考慮使用客戶程式碼。這樣做的優點/缺點是什麼？一方面，如果我有一個唯一標識符作為 PK 似乎是合乎邏輯的，我這樣做了。另一方面，我知道 string PKs 比 int PKs 慢 - 這個數據庫肯定會增長，但它永遠不會是數百萬行。這 3,000 名客戶的業務已超過 7 年，因此我們甚至需要很長時間才能達到數万行。
我研究過這個問題，辯論通常以“它取決於數據”結束——所以請教我……在這種情況下，你在規劃桌子時會考慮什麼？PK用什麼？無論如何，在其中粘貼一個自動遞增的 INT 有什麼好處嗎？索引和插入記錄有什麼問題嗎？
僅供參考，表格佈局只需要以下內容：
-CustomerCode(nvarchar(20)) -CustomerName(nvarchar(50)) -Address1(nvarchar(50)) -Address2(nvarchar(50)) - nullable -Address3(nvarchar(50)) - nullable -ZipCode (nvarchar(9))額外的問題 - 值得堅持使用 3NF 並製作一個單獨的表格，其中包含城市、州、郵政編碼作為 PK 並與客戶表格建立關係？或者不要擔心 3NF 並將城市/州保留在客戶表中以避免一些連接？
謝謝您的幫助！如果您需要任何其他詳細資訊，請告訴我。
優點 - 這是自然鍵，它是有道理的，它可能會被搜尋，我猜？
缺點 - 預設行為（完全可變）是主鍵是聚集索引。字母數字不是最佳候選，因為插入可能會導致頁面拆分，因為它們沒有像標識列那樣設置在不斷增加的值上。與字元數據（unicode 為 40+字節）相比，Int 標識列將佔用更少的空間（4 字節）。這會使您的其他索引更大，因為聚集鍵是其中的一部分。如果您改變了辨識客戶和製作客戶程式碼的方式，這一切都會中斷 - 使用代理可以使您免受這些類型的更改。
在這種情況下，我傾向於優化插入性能，並且經常使用標識列來處理聚集鍵和主鍵。我真的很喜歡整數聚集索引。（現在我知道您的問題不是關於聚集索引，而是關於主鍵……您仍然可以選擇其他一些列作為聚集索引並將其設為主鍵，您也可以對此設置唯一約束並處理它作為一個自然鍵，但不使其成為您的主鍵）。
我至少會用一個唯一的約束來索引它，並將它視為一個自然鍵。我只是不知道您是否真的需要將其設為主鍵。
Kimberly Tripp 是一位值得信賴的資源，她在她的部落格上對主鍵和（更多）集群鍵有很多話要說 - https://www.sqlskills.com/blogs/kimberly/guids-as-primary-keys-andor-集群鍵/
這只是我的意見 - YMMV。