我正在爲使用MySQL的電子商務網站設計數據庫。我已經列出了必要的表格列表以及表格所需的所有字段。我總共有9張桌子。作爲主鍵在所有表上自動遞增ID
我所做的是在所有表上包含一個自動遞增ID作爲主鍵。
除了2以外，我的所有表都歸一化爲3NF。兩個表'用戶'和'出口'未歸一化爲2NF。
一路上我意識到，使用自動遞增ID作爲主鍵時，規範化非常麻煩。由於規範化不是嚴格要求的，我想知道在所有表上使用自動遞增ID作爲主鍵是否有缺點？
我在我的時間創造了很多表。我只用了其中1/3的AUTO_INCREMENT。其餘的看起來像是一個「完美的」自然'PK'，所以我就這樣走了。
「正常形式」是一種教科書讓你開始的方式。在現實生活中（在我看來），NF後來在表現和其他考慮方面退居二線。
對於InnoDB表，您確實應該有一個明確PRIMARY KEY（auto_inc或自然）。
其中auto_inc會減慢速度的通用模式是多方面的：許多映射表，倫佐指出，而我在這裏討論：http://mysql.rjweb.org/doc.php/index_cookbook_mysql#many_to_many_mapping_table
在InnoDB中，該PRIMARY KEY存儲（羣集）的數據，所以索引結構（BTree）幾乎不佔用額外的空間。每個二級索引佔據一個單獨的BTree，隱式包含PK列。
在所有表中使用自動遞增ID作爲主鍵是很好的。這將幫助您自動索引數據。如果您打算給我們任何ORM（Doctrine2作爲示例），您必須爲每個表使用主鍵。
哪個ORM *要求*您在所有表中使用自動遞增鍵？我知道一些鼓勵它，但我不知道任何不允許自然鍵和複合鍵的ORM。這將是一個非常有限的框架。 –
正如我在重播中所提到的，Doctrine2更喜歡每個實體中的身份。當我們想從數據庫生成實體時，doctrine2必須要求標識列。 –
Doctrine 2.1支持複合主鍵，不需要自動遞增鍵。 http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/tutorials/composite-primary-keys.html –
你的問題被標記爲MySQL，所以我會指出MySQL的InnoDB存儲引擎使用主鍵作爲其所有表的聚簇索引。
如果可能，通過聚集索引進行查詢會更有效。但是，如果您有任意的規則，即使存在可以充當主鍵的另一列或一組列，所有表必須使用自動遞增主鍵，並且您始終運行按這些列而不是自動搜索的查詢 - 增量列，那麼你永遠不會獲得聚簇索引查詢的優勢。
我推薦使用GUID - uniqueidentifier作爲主鍵來否決將來的任何限制。
MSSQL：https://docs.microsoft.com/en-us/sql/t-sql/data-types/uniqueidentifier-transact-sql
的MySQL： https://forums.asp.net/t/1458664.aspx?UNIQUEIDENTIFIER+data+type+in+MySql
http://mysqlserverteam.com/storing-uuid-values-in-mysql-tables/
在橋表上自動遞增ID（即用於表示多對多關係的表）是無用的。如果你有這樣的桌子，你應該避開它們。 – Renzo
你可以在這裏找到更多有用的答案， [表中主鍵的練習]（https：// stackoverflow。com/questions/337503/whats-the-best-practice-for-primary-keys-in-tables）[專用主鍵字段]（https://stackoverflow.com/questions/166750/should-i-have-a -dedicated-primary-key-field）[特定前綴和自動編號]（https://stackoverflow.com/questions/506164/use-item-specific-prefixes-and-autonumber-for-primary-keys） – Haswin
你可以找到非常好的答案在這裏， [表中主鍵的最佳實踐]（https://stackoverflow.com/questions/337503/whats-the-best-practice-for-primary-keys-in-tables） [專用主要關鍵字段]（https://stackoverflow.com/questions/166750/should-i-have-a-dedicated-primary-key-field） – Haswin