添加數據庫關係以減少連接並提高性能

Question

我正在使用SQL Server 2008.我的問題是關於關係數據庫設計。 我得到了以下表格和關係：

合同：我與勞動者有1-M關係。我們預計有一半 一百萬合約。合同是雙方之間的商業合同。

勞動者：每組勞動者都屬於一份合同。我們預計有 百萬勞動力。

消息：預計將包含數百萬條記錄。信息被髮送到 合同方關於合同和勞工。

MessageContract：消息和合同之間的橋接表，並且 預計有數百萬條記錄。

MessageLaborer：Message與Laborer之間的橋表， 預計有數百萬條記錄。

處理：與消息具有1-M關係。預計最終會有 數十萬條記錄。

我的問題是，除了Process和Message之間的關係外，我是否可以在Process和MessageContract和MessageLaborer之間添加一個關係，所以當查詢合同和勞工正在處理時，我不必添加一個帶有Message的連接。

另一個示例：MessageLaborer與MessageContract具有間接關係。在任何時候，您可以通過查詢數據庫來獲取每個合同消息下的勞動者，但是您需要4個連接來完成此操作。另一個選項是在MessageLaborer和MessageContract之間創建另一個關係，所以你只需要一個連接。

這是常見做法還是常見錯誤？

Answer 1

只有當它們具有多對多關係時在兩個關係之間建立橋接表纔有意義 - 它將多對多解析爲一對多對一。

如果您需要定義一條消息，然後將其發送到多個合同，則在消息和合同之間使用橋接表。如果消息僅適用於單個合同，則不需要橋接表。

不要引入新表來加入已經自然加入的關係。你將打破標準化形式的能力，爲每一個事實提供單一的真理來源。但是，如果您有父級的兩個子表，如果通常無需通過加入其外鍵列而不通過父表就可以在它們之間進行連接。

Answer 2

數據庫設計中最常見的錯誤是添加太多關係。實現1：N關係非常複雜。編寫客戶端應用程序以更新始終有兩個地址的客戶很容易。爲0..N地址的客戶編寫客戶端應用程序要困難得多。

例如，如果郵件最多隻能與一個合同有關，則可以刪除MessageContract表。現在創建消息的客戶端（或業務層）擁有少一張擔心的表。顯示消息的客戶端可以使用列表框而不是gridview。非常容易！

Answer 3

您可以將關係數據庫建模過程想象爲讓系統意識到現實世界的一部分。所以，如果在你的DB必須知道的現實世界中存在關係，那麼也應該有一個真正的數據庫關係。

不要因爲您需要JOIN而添加數據庫關係。這部分屬於查詢優化。