數據庫主鍵和驗證

Question

'你好，我是一名大學生，學習計算。我目前正在開展我的課程工作（這需要創建一個數據庫），我希望你能爲我解決一些問題。附註：不具體編程。

1）你可以使用字符串作爲主鍵，即MemberName嗎？ 2）主鍵是否需要在其名稱中包含「ID」？ 3）如果您要使用名稱作爲主鍵，您是否可以使用驗證技術來確保每個名稱都是唯一的？

我目前完成了大部分課程，假設我可以使用名稱作爲主鍵和驗證來確保它們是唯一的，因爲我們在課程之前創建的示例數據庫運行的原理相同。然而，我的老師（一位新老師）告訴我，我需要重新做我的工作，我正在努力尋找一種不必重新做所有事情的方式，因爲我諮詢了我們的學習資源，不能找到任何原因必須使用主鍵的整數或任何不能使用驗證的原因。

Answer 1

1）您可以將字符串列作爲主鍵，但正如已經指出的那樣，這不是明智的。該值可能會更改，對引用它的任何內容的密鑰無效，並且通常需要刪除數據行並將其重新插入新密鑰。密鑰的存儲也不太可能有效。一個64位的標識符（典型情況）將比長於8個ASCII字符的任何名稱使用更少的空間。任何鏈接到主鍵的查詢都將在鍵之間進行比較，如果它們與硬件對齊，這幾乎肯定是64位，那麼這些查詢將是最有效的。

2）命名約定可以非常強大，因此在列名中包含一個指示符以表明它是主鍵是明智的。我個人不喜歡使用ID作爲這個，因爲我有太多的數據庫有一個實際的ID字段（如僱員ID發佈Y/N），這會導致混淆。我更喜歡將PK_tablename作爲主鍵名（對於鏈接到它的外鍵使用FK_tablename），但從SQL的角度來看，在名稱中包括任何標準肯定是可選的。

3）您可以使用驗證技術來確保插入之前的唯一性，但這是另一個反對使用任何內容而不是無意義數字作爲關鍵字的論據。很容易忽略密鑰的併發問題。如果兩個進程試圖同時插入相同的名稱，並且每個進程首先檢查是否存在（唯一性），則可能會出現死鎖或其他賽車情況。幾乎所有的數據庫都能保證可以自動生成默認的關鍵數據類型（通常是64位）。這可以讓你插入一行，無論如何，並確保每一行都有一個唯一的ID。如果將驗證包裝到事務中以強制同時按順序插入相同的密鑰，則可能會導致性能下降或出現其他死鎖問題。

你的教授是對的。最好使用默認密鑰數據類型，即使您不需要。

Answer 2

這裏有一些快速的答案

1. 您可以使用字符串作爲主鍵，但它通常是一個壞主意。主鍵通常被編入索引，並且使用數值通常意味着您的主鍵在字節方面更小，因此創建索引時佔用的存儲空間更少，並且在連接期間執行得更快，或者作爲可能創建的其他索引的一部分執行。定義一個可以改變的東西的密鑰通常也是一個壞主意。如果您在MemeberName上定義了一個密鑰並且用戶想要對其進行更改，則由於其他表可能會引用您的MemberName主鍵作爲該表中的外鍵，因此很難進行該更改。

2. 列名不影響它是否可以定義爲主鍵。您甚至可以將多個列定義爲主鍵（稱爲複合主鍵），只要列集合生成唯一記錄即可。

3. 嘗試插入重複主鍵時，數據庫會給您一個錯誤，但如果使用基於數據輸入的字符串值，您最好在插入前檢查它是否存在。

Answer 3

如果在給定情況下使用字符串是有意義的，那麼使用字符串作爲關鍵字沒有什麼根本性的錯誤。無論數據類型是什麼，都需要唯一的唯一標識符。除了唯一性和最小化之外，在選擇或設計密鑰時還應注意三個其他特性：簡單性，穩定性和熟悉性。在實踐中，人們通常會發現使用文字和字母而不僅僅是數字來記住和使用它更簡單，這就是爲什麼字母數字標識符很常見（例如汽車牌照，航空公司航班號，座位預訂號碼，州和國家代碼，郵政編碼， 電子郵件地址）。有研究和證據證明字母數字鍵比單獨使用數字更有用。此外，字母數字標識符通常可能比數字標識符短。

在你的情況下，如果MemberName是一個人的名字，那麼很可能它不是標識符的實際選擇，因爲不同的人通常有相同的名字。另一方面，在某些情況下，個人「名稱」確實是一個關鍵 - 例如用戶的網站登錄名。您需要根據您要解決的問題來決定這些事情。