沒有主鍵的MySQL表（最佳實踐）

我有一個表users其中包含幾個用戶信息。我想將用戶特定的權限存儲在不同的表中。沒有主鍵的MySQL表（最佳實踐）

我是否需要在user_permissinos表中有主鍵up_id，即使它不會在任何地方使用？我知道總是建議在表中有一個主鍵，但在這種情況下對我來說沒有意義。如果我需要連接兩個表，我將加入user_id的up_of_user。

Table `user` 
========================== 
user_id int(11) PK AI NN 
user_name varchar(50) 
... 


Table `user_permissions` 
======================================= 
up_id int(11) PK AI NN 
up_of_user int(11) FK of user.user_id 
up_edit_post tinyint(4) DEFAULT '0'

來源

2017-08-14 btx

'up_of_user'不會是'user_permissions'的候選主鍵嗎？ –

'up_of_user'將是'user'表的外鍵。 –

據我所知，外鍵不能是主鍵。但我可能是錯的。 – btx

請閱讀的MySQL的文檔：

一個表的主鍵代表列或一組您在最重要的查詢中使用的列。它有一個關聯索引，用於快速查詢性能。查詢性能受益於NOT NULL優化，因爲它不能包含任何NULL值。藉助InnoDB存儲引擎，表格數據在物理上組織成可以基於主鍵列或多列進行超快速查找和排序。

如果您的表格很重要，但沒有明顯的列或一組列作爲主鍵，那麼您可以創建一個帶有自動增量值的單獨列作爲主鍵。當您使用外鍵連接表時，這些唯一ID可用作指向其他表中相應行的指針。

從我的經驗和知識，如果你不定義你的主鍵數據庫將創建一個隱藏的主鍵。在你的情況下，我應該保留主鍵。

感謝@AaronDigulla對他的解釋...：

有必要嗎？沒有。在幕後使用？那麼，它被保存到磁盤並保存在行緩存中，等等。刪除會稍微提高你的性能（使用毫秒級精度的手錶來注意）。

但是......下一次有人需要創建對此表的引用時，他們會詛咒你。如果他們很勇敢，他們會添加一個PK（並等待很長時間讓DB創建該列）。如果他們不勇敢或愚蠢，他們將開始使用業務密鑰（即數據列）創建引用，這將導致維護噩夢。

結論：由於擁有PK（即使不使用ATM）的成本太小，所以應該這樣做。

來源

2017-08-14 12:23:12 Noob

InnoDB的有PK的3種選擇：爲了，

明確PRIMARY KEY(...) - 最佳實踐：始終做到這一點。
第一個UNIQUE(...)與所有NON NULL列。 - 比＃1更快。
一個隱藏的6字節〜整數。 - 由於它被隱藏起來，所以很難在桌面上進行維護。

AUTO_INCREMENT與「自然」 PK：

第一條規則：如果你有一個自然鍵，使用它，而不是添加人工ID。我創建的表格中大約2/3具有「自然」PK，有時是「複合」（多列）。

第二條規則：如果你有一個以上的次級索引，它可能需要更少的空間使用人工智能PK。這是因爲每個輔助鍵都包含PK的副本。

第三條規則：對於只有一個二級索引，這是一個折騰。

例子

老妻子的故事又名「假新聞」

「來的大PK慢」 - 也許，也許不是。
「一個VARCHAR PK很慢」 - 不是太多。

如果你還有其他的積蓄（例如，擺脫一列），那可能會覆蓋舊妻子的故事。

你的榜樣

折騰up_id促進user_name是PK。

這聽起來像user和user_permissions是一個1：1的關係？這是非常難得的有兩個相同的PK表。通常這兩個表應該合併爲一個。

來源

2017-08-18 22:29:32

沒有主鍵的MySQL表（最佳實踐）

回答

相關問題