在一個表中有幾個外鍵是不是很好的做法？

考慮下面的表結構：在一個表中有幾個外鍵是不是很好的做法？

titles(titleID*, titleName) 
platforms(platformID*, platformName) 
products(platformID*, titleID*, releaseDate) 
publishers(publisherID*, publisherName) 
developers(developerID*, developerName) 
products_publishers(platformID*, titleID*,publisherID*) 
products_developers(platformID*, titleID*, developerID*)

產品表使用platformID和titleID的兩個外鍵一個木匠表。這是因爲某些標題在不同平臺上具有相同的屬性。爲了避免數據重複，我創建了joiner表。

當我創建一個products_publishers表時，出現了我的問題。因爲一個產品可以有多個發佈者，所以我必須創建一個由三個外鍵組成的連接器表。這是最佳做法嗎？我的場景可以讓我創建一個包含四個這樣的條目的表格。我考慮使用列來將這些數據存儲在產品表中，並放棄連接器表和發佈器表，但直觀上這不太合適。

有什麼想法？

非常感謝

來源

2010-02-19 Mohamad

-1：你能解釋一下爲什麼你懷疑在一張桌子上有幾個外鍵可能不好？ – 2010-02-19 13:12:57

我的理由是，在包含多個外鍵的表上執行查詢可能會降低性能，因爲默認情況下查詢將不得不查詢其他幾個表。 – Mohamad 2010-02-19 13:38:56

這是非常正常的，並稱爲複合鍵。我見過的另一個常見策略是與其他所有表一樣，爲表提供一個主鍵（代理鍵）。其中部分原因做：

一致的數據模型，其中每個你的表有一個主鍵
它makesjoining更容易和更快太上的一個鍵相比組合鍵加入
如果您使用ORM的數據模型，它通常會得到更好的支持，並且使您的代碼更易於處理單個鍵而不是單個鍵。

我個人認爲兩個複合鍵是可行的，但一旦你有三個或更多，你應該考慮引入代理鍵。您選擇哪種策略，您只需要在數據模型中保持一致。

來源

2010-02-19 13:06:16

非常感謝，我將在我的產品表中實施代理鍵。我可以看到性能方面的好處本身就值得。 – Mohamad 2010-02-19 13:20:53

這是完全可以的，而且在實踐中很常見。我認爲我用過的每個數據庫都有這樣的表格。

來源

2010-02-19 12:50:33

我會說，是的，這是最好的做法，在產品表中使用額外的列將會阻止您在多個平臺上使用產品。

你能想到的是哪些字段應該屬於joiner表中的關鍵字。如果例如每個平臺和標題只能有一個發佈商，然後publisherID不應該是products_publishers密鑰的一部分。

來源

2010-02-19 12:55:44 chros

同意。在許多項目中，我們在一些表中使用了2-3個外鍵。它運行良好，我無法爲許多關係問題想出更好的解決方案 - 我也從未見過。

來源

2010-02-19 13:00:55

在一個表中有幾個外鍵是不是很好的做法？

回答

相關問題