MySQL - 自動增量+複合主鍵 - 性能和完整性

Question

我有一個數據庫設計，使用複合主鍵來確保唯一性，哪些也是外鍵。

這些表然後以相同的方式鏈接到其他表，以便最終複合鍵可以達到4或5列。這導致了一些相當大的JOIN，所以我認爲一個簡單的解決方案是使用一個自動增量列，它不是主鍵的一部分，而是用作其他表的主鍵的一部分。

下面是該總體佈局一些僞代碼：

CREATE TABLE Item (
id AUTO_INCREMENT, 
... 
PRIMARY KEY (id) 
) ENGINE = InnoDB; 

CREATE TABLE PriceCategory (
id AUTO_INCREMENT, 
... 
PRIMARY KEY (id) 
) 

CREATE TABLE ItemPriceCategory (
itemId, 
priceCategoryId, 
id AUTO_INCREMENT, 
... 
UNIQUE INDEX id, 
PRIMARY KEY (eventId, priceCategoryId) 
) 

CREATE TABLE ClientType (
id AUTO_INCREMENT, 
... 
PRIMARY KEY (id) 
) 

CREATE TABLE Price (
itemPriceCategoryId, 
clientTypeId, 
id AUTO_INCREMENT, 
... 
UNIQUE INDEX id, 
PRIMARY KEY (itemPriceCategoryId, clientTypeId) 
) 

table Purchase (
priceId, 
userId, 
amount, 
PRIMARY KEY (priceId, userId) 
) 

表的名稱已被更改，以保護無辜;-)而且實際的佈局中引用的條款深入一點。

所以，我的問題是，從性能和數據完整性的角度來看，這是一個可行的策略嗎？從Purchase表中的所有引用表中獲取所有密鑰會更好嗎？

在此先感謝。

Answer 1

通常，關於主鍵的建議是讓一個列具有「無意義的」，不可變的主鍵。自動遞增整數很好。

所以，我會扭轉你的設計 - 你的連接表也應該有無意義的主鍵。例如：

CREATE TABLE ItemPriceCategory (
itemId, 
priceCategoryId, 
id AUTO_INCREMENT, 
... 
PRIMARY KEY id, 
UNIQUE INDEX (eventId, priceCategoryId) 
) 

這樣一來，在價格上itemPriceCategoryId列是正確的外鍵，鏈接到ItemPriceCategory表的主鍵。

然後，您可以使用http://dev.mysql.com/doc/refman/5.5/en/innodb-foreign-key-constraints.html外鍵來確保數據庫的一致性。

在性能，從廣義上講而言，這種策略應該比聯接查詢複合鍵，可快速，但具有良好索引的數據庫，你實際上可能沒有注意到其中的差別...

Answer 2

我認爲，在這裏翻譯的東西已經丟失了，但我盡了最大努力製作了這個圖表。

一般來說，有兩種方法。第一個是傳播密鑰，第二個是對每個表都有一個自動增量整數作爲PK。

第二種方法通常通過它們使用DB作爲對象的持久性存儲ORM工具驅動，而第一個（使用密鑰傳播）更常見的是手工製作的DB設計。

通常，具有關鍵傳播的模型爲「隨機查詢」提供更好的性能，主要原因是您可以在連接中「跳過表」。例如，在具有關鍵傳播的模型中，您可以將Purchase表直接加入Item表，以便通過ItemName報告購買。在另一個模型中，您將不得不加入Price和ItemPriceCategory表格 - 只需要進入ItemID即可。

基本上，具有關鍵傳播的模型基本上是關係型的，而另一個是對象驅動的。 ORM工具可以選擇或強制使用單獨的ID（第二種情況），但爲開發提供其他優勢。

你的例子似乎試圖使用這兩種組合 - 不一定是壞的，它會幫助你，如果你可以與原設計師談話。

---

隨着鍵傳播

---

爲每個表