沒有主鍵的表

Question

因此，我總是被告知，用表指定主鍵是絕對必要的。 我一直在做一些工作，遇到主鍵的唯一約束會阻止我需要添加的數據的情況。

如果有一個示例情況，其中表是由字段構成的：

Age, First Name, Last Name, Country, Race, Gender

如果要輸入大量數據，那么所有這些字段都不一定唯一地標識一行，而且我也不需要跨所有列的索引。 這里唯一的解決方案是制作一個自動遞增的ID字段嗎？ 根本沒有小學可以嗎？

Answer 1

不一定總是需要一個主鍵，大多數DBMS都會允許您構造一個沒有一個^（a）的表。

但這並不一定意味着它是個好主意。 考慮一下要使用該數據的情況。 現在考慮一下是否有兩名來自珀斯的二十歲的澳大利亞人鮑勃·史密斯。

在沒有唯一約束的情況下，您可以將兩行都放到表中，但是她很費力 。 您如何確定將來要使用哪一個？ ^（b）

現在，如果你只是想保存的事實，有符合這些標准的一個或更多的人，你只需要存儲一行 。 但是，您可能會擁有一個由所有列組成的復合主鍵。

如果您要存儲有關此人的其他信息（例如，在其iPhone上的“ 2048”游戲中得分最高），那么您就不需要整個行中的主鍵，而只是您提到的各列中的主鍵。

不幸的是，這無疑意味着，當鮑勃·史密斯這兩個鮑勃·史密斯都試圖將他們的高分寫到數據庫中時，卻發現他們中的一個丟失了信息，這無疑是一個時刻。

如果您既要在表中同時使用它們，又要考慮上述可能性（您提到的列中兩個人的屬性相同），那么最好的辦法是引入一個人工鍵，例如自動遞增列，首要的關鍵。 這將使您能夠唯一地標識一行，而與其他列的相同程度無關。

人工密鑰的另一個優點是，由於具有任意性，因此無需為已識別的事物進行更改。 在您的示例中，如果您在主鍵中使用年齡，姓名，國籍或位置^（c） ，則所有這些都可能會發生更改，這意味着您將需要調整引用這些行的任何外鍵。 如果引用這些行的表使用不變的人工鍵，那將永遠不是問題。

---

^（a）在某些情況下，主鍵並沒有真正給您帶來任何性能上的好處，例如當表特別小時（例如，將整數1到12映射到月份名稱）。

換句話說，全表掃描實際上並不比索引慢。 但是這些情況極為罕見，我可能仍會使用鍵，因為它更加一致（尤其是因為使用鍵往往不會對性能產生任何影響 ）。

---

^（b）請記住，我們這里所說的是實踐而不是理論。 在實踐中，雖然您可以創建一個沒有主鍵的表，但是關系理論指出，每一行都必須是唯一可識別的，否則就無法維護關系。

CJ Date與Codd一起是關系數據庫理論的始祖之一，他在“數據庫系統簡介”中陳述了關系表的規則，其中之一是：

記錄具有唯一的標識符字段或稱為主鍵的字段組合。

因此，就關系理論而言，每個表都必須有一個主鍵，即使實際上並不總是需要它。

---

^（c） 特別是可以保證每年更改直到您去世的年齡，因此也許生日對於該專欄來說是更好的選擇。

Answer 2

這里唯一的解決方案是制作一個自動遞增的ID字段嗎？

這是一種有效的方法，但不是唯一的方法：您可以使用其他方法來生成唯一鍵，例如使用GUID 。 這樣的鍵稱為代理主鍵 ，因為它們與數據行的“有效負載”無關。

根本沒有小學可以嗎？

由於您提到行中的實際數據可能不是唯一的，因此如果沒有主鍵，您將無法有效地使用表。 例如，您將無法更新或刪除特定行，例如，當用戶名更改時，這可能是必需的。

Answer 3

最簡單的解決方案是包括一個ID列作為主鍵：

id int not null primary key auto_increment

Answer 4

通常，應避免在數據庫中擴散ID主鍵字段。

現在，這並不意味着您不應該具有主鍵，您的主鍵可以是代理鍵或組合鍵。 這就是您應該在此處執行的操作。

如果這些字段{年齡，名字，姓氏，國家/地區，種族，性別}明確地標識了每一行，然后做一個由所有這些字段組成的主鍵。

但是，如果沒有，那么您必須具有其他類型的信息才能消除數據歧義。

您也可以不指定任何類型的鍵，並假定該表為非規范化和冗余數據源...如果這是您需要的...！

Answer 5

從您的帖子中，它看起來像代表一個person實體的表格。 在這種情況下，沒有PK會唯一確定每個人的實體。 我建議，在桌子上有一個主鍵，它將唯一地確定每個人的記錄。

您可以創建一個AUTO_INCREMENT ID列（綜合ID列）

（要么）

您可以在表中合並多個列，這些列可以唯一地確定所有其他字段，例如(First Name, Last Name) ，這可能會使它成為一個復合主鍵，但也可能會發生沖突，因為可能會有多個人擁有相同的完整鍵名稱（名字+姓氏）。

Answer 6

將標識列與其他列（例如姓氏）一起使用