SQL主鍵 - 是否有必要？

我有一個項目列表。大多數這些項目將不會有貨。項目表具有ID，名稱，說明。物料的數量存儲在名爲庫存的另一個表中。庫存表具有item_id和庫存物料的數量。SQL主鍵 - 是否有必要？

我是否需要庫存表的主鍵？如果是這樣，我應該使用串行密鑰還是複合密鑰？什麼時候表可以沒有主鍵？

編輯：謝謝大家的信息豐富。除了非常罕見的例外，我現在總是有主鍵。我還學習了更多關於串口和複合鍵的知識。

2012-01-08 deadghost

** ANY **實數據表需要一個主鍵 - 這是唯一標識表中每一行的方法。爲什麼你會**沒有**想要一個PK超越了我.....在表上沒有主鍵的唯一情況可能是臨時表來批量加載數據或類似的東西。 .. – 2012-01-08 12:37:29

@mark_s沒有任何問題的聯繫，但我有私人意見，在非常特殊的情況下，我可以更好地利用堆，比基於PK的表8）讓我們去聊天？ – 2012-01-08 12:39:11

@mark_s是的，只是批量加載的堆規則8-） – 2012-01-08 12:43:53

始終瞄準擁有主鍵。

如果你不確定，有一個主鍵。

即使你99.99％確定你不需要它，有一個。我通過多年的經驗瞭解到需求的變化。

我真正能想到的唯一例子是多對多的表，只有兩個foreign_keys和巨大（數億行）的表，每個字節都是有效的。但即便如此，仍然強烈建議使用單獨的，獨特的無業務價值ID密鑰。

有這方面的一些更偉大的信息在這裏：
http://weblogs.sqlteam.com/jeffs/archive/2007/08/23/composite_primary_keys.aspx

這裏：
http://www.techrepublic.com/article/the-great-primary-key-debate/1045050
這裏：
http://databases.aspfaq.com/database/what-should-i-choose-for-my-primary-key.html
這裏：
Should I use composite primary keys or not?

在你的榜樣，我肯定會有一個。

「不」的決定應該基於非常明確的需求和理解以及實際或預測（例如數量）具有問題的問題。

調試和故障排除時會出現這種需求的一個很好的例子。就像創建和更新每個表中的列（我的另一個最愛）一樣，此信息最初可能不會用於/前端，但男孩可以幫助追蹤和解決問題。（順便說一句更新的郵票往往是現在這個樣子Ruby on Rails的這也與具有id場的每個表的慣例運作良好的框架標準！）

來源

2012-01-08 12:39:39

'我真正能想到的唯一例子是多對多的表，只有兩個foreign_keys'--爲什麼不把這兩個外鍵變成複合主鍵呢？ – gldraphael 2017-01-12 01:50:27

如果每個項目只有一個盤點行 - 那麼它會便宜很多（均值 - CPU和IO），這將是在同一個項目表，

如果沒有 - 它依賴。而且它不會在所有

歸一化數據，但據我瞭解這個問題，如果你兩個表堅持 - 是的，它能夠更好地對ITEM_ID場

來源

2012-01-08 12:37:39

我仍然在研究是否應該將兩個表合併在一起，有些事情感覺不對。感覺每個表格中描述的實體是相似的，但不完全相同。 – deadghost 2012-01-08 13:41:51

兩張桌子只有在您有類似物品以其獨立價格交付的情況下才有理由，否則您可以輕鬆地將它們合併在一起 – 2012-01-08 13:44:36

嗯，好吧，您的積分已被拍攝。我會將它們合併在一起。我已經斷定數量屬於項目實體。我的推理是項目表描述了每一行中的一個項目，並且該數量仍在描述該項目。也許我會將表格重命名爲Items，因爲每行描述的項目不僅僅是單個項目...或者不是，因爲1項目非常愚蠢。 – deadghost 2012-01-08 13:54:48

指數一般：每張桌子都應該有一個PK。至少每個表都應該有一些CLUSTER索引。 PK不能是一個特殊的列，但是在系統（RDBMS）中沒有唯一標識的行不是很好的做法。

可能有幾種情況下不需要PK，但這是規則中的例外。

來源

2012-01-08 12:38:17 TcKs

聚集索引是索引的物理實現細節，與是否需要PK的問題完全無關。此外：並非每個DBMS *都有*聚簇索引 – 2012-01-08 12:43:16

a_horse_with_no_name：如果DBMS沒有用戶定義的集羣索引，那麼DBMS有一些自己的內部方式，如何佈線數據。當然 - 如果你的數據庫管理系統是這種情況，請忽略我關於該數據庫系統的CLUSTER的說明:)。 – TcKs 2012-01-08 13:30:33

如果item_id在庫存表中是唯一的，我會說你用它作爲標識符是很好的。主鍵通常用於唯一標識一條線，但您可以看到您的情況下的庫存線標識沒有用處。

編輯：正如其他人已經指出，通常如果你沒有一個主鍵的好理由，你會很滿意地看着你的表結構，看看你是否可以將它與另一個表合併，在這案件可能是項目表。我可以看到這種情況不是一種選擇（例如，您不能更改模式，只需添加新表），但值得一看。

來源

2012-01-08 12:38:43

我需要的庫存表的主鍵？

我們可以假設數據是關係型的嗎？根據定義，關係沒有重複的元組。 SQL允許在表中存在重複行。因此，爲確保實踐中不存在重複行，每個表至少應有一個唯一約束。長話短說，最好有一個很好的理由，不要在表中的每個候選鍵上設置唯一的約束。根據定義，零個或一個候選鍵可以被指定爲「主要」，並且哪一個（如果有的話）應該接收該指定是任意的。

我應該使用串行密鑰還是複合密鑰？

我認爲這是一個錯字。單列鍵被稱爲「簡單鍵」而不是「序列鍵」。根據您的描述，您的庫存表在item_ID which is a simple key上僅有一個候選人候選人密鑰。唯一可能的組合鍵是超級鍵，除非它被外鍵引用，否則不應該使用唯一約束來約束。

什麼時候表可以沒有主鍵？

當所有候選鍵已被限制使用UNIQUE約束或當表不打算保存關係數據。

來源

2012-01-09 15:06:02 onedaywhen

SQL主鍵 - 是否有必要？

回答

相關問題