在數據庫中有「外鍵冗餘」是否不好？

我設計一個數據庫結構與下面的簡單示例：在數據庫中有「外鍵冗餘」是否不好？

Team has many members 
Member has many clients 
Client has many projects

假設我的對象有這些參數：

Team: id, type 
Member: id, team_id, name 
Client: id, member_id, email 
Project: id, client_id

這是很簡單的找到項目的客戶端或客戶端的成員，或一個成員的團隊。

但是，假設我想找一個項目的團隊，例如，我必須先找到一個項目的客戶，然後是客戶的成員，然後是成員的團隊。

我可以直接添加TEAM_ID到項目中，像這樣：

Project: id, client_id, team_id

我知道，然而，這增加冗餘一定程度，因爲這些信息是可通過「漲的關係樹「。這是一個壞主意嗎？

謝謝！

難道你不是指「每個團隊成員有很多客戶」，「每個團隊成員的客戶有很多項目」嗎？ – 2012-08-08 01:07:31

你認爲「有害冗餘」是什麼？你是否在談論與歸一化理論相關的同一種「有害歸約」？或者，您是衡量什麼是「有害」的另一種措施？ – 2012-08-08 10:42:40

這是否是一個壞主意取決於數據庫的典型用例。

添加額外的外鍵增加了修改結構（INSERT，UPDATE，如果修改關係，DELETE）的成本。

不是具有額外的外鍵增加了查詢的成本，否則這些查詢的成本會因其存在而受益。

如果項目結構變化不大，但您經常查詢結構，額外的外鍵很可能是淨積極的。如果有疑問，請使用合理的測試數據創建結構，並對您認爲典型的一些查詢進行基準測試。

2012-08-08 00:34:53

您不必添加FK。您可以簡單地製作FKs複合材料。 – 2012-08-08 00:37:59

儘管如此，您管理的密鑰越大，更新速度越慢。即使您擁有更寬的密鑰，您仍然可以在磁盤頁面上放置更少的密鑰，並且可以將更少的密鑰緩存在可用的RAM中。 – 2012-08-08 02:52:25

這不像你必須在這裏做4個查詢。您只需在單個查詢中加入所有表即可。這不會增加很多複雜性，但它確實增加了一點。我會隨你所擁有的一起去。

2012-08-08 00:39:04

回答