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

Question

我有一個數據庫設計，該數據庫使用復合主鍵來確保唯一性，並且這也是外鍵。

然后將這些表以相同的方式鏈接到其他表，以便最終復合鍵最多可以包含4或5列。 這導致了一些相當大的JOIN，因此我認為一個簡單的解決方案是使用一個autoincrement列，該列不是主鍵的一部分，而是用作其他表的主鍵的一部分。

這是一些顯示一般布局的偽代碼：

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)
)

這樣，price中的itemPriceCategoryId列是正確的外鍵，鏈接到ItemPriceCategory表的主鍵。

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

從性能上來說，從廣義上講，此策略應該比查詢聯接中的復合鍵更快，但是對於索引良好的數據庫，您實際上可能不會注意到其中的區別。

Answer 2

我認為在這里的翻譯中有些東西丟失了，但是我盡了最大的努力對此做了一個ER圖。

通常，有兩種方法。 第一個是傳播密鑰，第二個是為每個表使用一個自動遞增的整數作為PK 。

第二種方法通常由ORM工具驅動，后者使用DB作為對象持久性存儲，而第一種方法（使用密鑰傳播）在手工設計的DB設計中更為常見。

通常，具有鍵傳播的模型可為“隨機查詢”提供更好的性能，這主要是因為您可以在聯接中“跳過表”。 例如，在具有密鑰傳播的模型中，您可以將Purchase表直接連接到Item表，以按ItemName報告購買。 在另一個模型中，您也必須加入Price和ItemPriceCategory表-只是要獲得ItemID 。

基本上，具有密鑰傳播的模型本質上是關系型的-而另一個模型是對象驅動的。 ORM工具更喜歡或使用具有單獨ID（第二種情況）的模型，但為開發提供了其他優勢。

您的示例似乎正在嘗試使用這兩者的某種組合-不一定很糟糕，如果您可以與原始設計師交談，將會很有幫助。

---

隨着密鑰傳播

---

每個表的獨立鍵