我能夠在一個表中擁有多個主鍵嗎？

我能夠在一個表中擁有多個主鍵嗎？

---

#1樓

以比我能作的更好的方式給出了良好的技術答案。 我只能添加到這個主題：

若是你想要一些不容許/不可接受的東西，那麼就有理由退一步。

1. 理解爲何它不被接受的核心。
2. 在文檔/期刊文章/網絡等方面進行更多挖掘
3. 分析/審查當前的設計並指出主要缺陷。
4. 在新設計期間考慮並測試每一步。
5. 始終期待並嘗試建立自適應解決方案。

但願它會幫助某人。

---

#2樓

主鍵是惟一標識記錄的密鑰，用於全部索引。 這就是爲何你不能有多個。 它一般也是用於鏈接子表的密鑰，但這不是必需的。 PK的真正目的是確保某些內容容許您惟一地標識記錄，以便數據更改影響正確的記錄，從而能夠建立索引。

可是，您能夠將多個字段放在一個主鍵中（複合PK）。 這將使您的鏈接速度變慢（特別是若是它們是更大的字符串類型字段）而且您的索引更大但它可能會刪除在某些子表中進行鏈接的須要，所以就性能和設計而言，請將其鏈接到一個案例案例基礎。 當你這樣作時，每一個字段自己並非惟一的，但它們的組合是。 若是組合鍵中的一個或多個字段也應該是惟一的，那麼您須要一個惟一索引。 儘管若是一個字段是惟一的，這多是PK的更好的候選者。

如今有時，你有不止一個PK的候選人。 在這種狀況下，您選擇一個做爲PK或使用代理鍵（我我的更喜歡這個實例的代理鍵）。 而且（這很關鍵！）您爲每一個未被選爲PK的候選鍵添加惟一索引。 若是數據須要是惟一的，則不管是否爲PK，都須要一個惟一的索引。 這是一個數據完整性問題。 （注意，只要您使用代理鍵，這也是正確的;人們遇到代理鍵時會遇到麻煩，由於他們忘記在候選鍵上建立惟一索引。）

有時你須要一個以上的代理鍵（若是你有它們一般是PK）。 在這種狀況下你想要的不是更多的PK，而是帶有自動生成鍵的更多字段。 大多數數據庫不容許這樣作，但有辦法繞過它。 首先考慮是否能夠根據第一個自動生成的密鑰（例如Field1 * -1）計算第二個字段，或者是否須要第二個自動生成的密鑰實際上意味着您應該建立一個相關的表。 相關表能夠是一對一的關係。 您能夠經過將父表中的PK添加到子表，而後將新的自動生成字段添加到表中，而後將適用於此表的任何字段添加到子表中來強制執行此操做。 而後選擇兩個鍵中的一個做爲PK並在另外一個上放置惟一索引（自動生成的字段沒必要是PK）。 並確保將FK添加到父表中的字段。 一般，若是子表沒有其餘字段，則須要檢查爲何您認爲須要兩個自動生成的字段。

---

#3樓

您只能擁有一個主鍵，但主鍵中能夠有多個列。

您還能夠在表上使用惟一索引，這將有點像主鍵，由於它們將強制執行惟一值，並將加快查詢這些值。

---

#4樓

表能夠有一個複合主鍵 ，它是由兩列或更多列組成的主鍵。 例如：

CREATE TABLE userdata (
  userid INT,
  userdataid INT,
  info char(200),
  primary key (userid, userdataid)
);

更新： 這是一個連接 ，其中包含複合主鍵的更詳細說明。

---

#5樓

有些人使用術語「主鍵」來表示一個整數列，它經過某種自動機制生成其值。 例如，MySQL中的AUTO_INCREMENT或Microsoft SQL Server中的IDENTITY 。 你是否在這個意義上使用主鍵？

若是是這樣，答案取決於您正在使用的數據庫的品牌。 在MySQL中，你不能這樣作，你獲得一個錯誤：

mysql> create table foo (
  id int primary key auto_increment, 
  id2 int auto_increment
);
ERROR 1075 (42000): Incorrect table definition; 
there can be only one auto column and it must be defined as a key

在某些其餘品牌的數據庫中，您能夠在表中定義多個自動生成列。