SQL：關係數據庫設計 - 多FKS給同桌

我希望有人能告訴我，這將是壞的數據庫設計：SQL：關係數據庫設計 - 多FKS給同桌

比方說，我有兩個表：

Person 
Contract

而且我們說我得到兩種類型的合同，一個合同（只涉及一個人）和一個合同（涉及兩個人）。沒有其他排列。

這將是最簡單的設置合同表有兩個FK領域，其中之一是爲空的，即：

合同：

ContractID  Description    PersonID  PersonID_Second 
1    Single person contract 1112   NULL 
2    Joint contract   1073   900

這是一個壞主意？

感謝
卡爾

來源

2011-03-30 Karl

兩毛錢：兩人之間的關係與合同等價嗎？是否有「第一」人，「乘坐第二人」的人，還是他們在這份合同方面同等重要？而且，單人和雙人（以及未來可能的N人）之間的區別是合同的一個重要屬性？

如果關係是相同的，那麼請與Mitch的多對多解決方案一起使用。
如果第一和第二之間有一個重要的區別，Parched Squid的[說讓我的早晨更好！]多個FK修復會運行良好。
但是，如果您預先考慮N人合同，請堅持使用多對多關係表，並在關係表中指定「正在指定哪個」關係。
如果您需要對合同進行排序以查找或排序1,2或N個人，則可能更方便的是擁有指示合同類型的額外屬性，而不是實施大量的聯合和空檢查邏輯來統計每個合同的相關人員。

來源

2011-03-30 13:43:45

感謝所有的評論。這裏兩個人確實有區別。一個是合同持有人，另一個是「隨行」，如你所示。以這種方式分配到合同的人數增加的概率不是零，而是足夠小。我更擔心用戶將3人以上分配給同一份合約 - 目前有100％的機會出錯。儘管如此，這並不排除使用M：N關係，它只需在ContractPerson表中具有適當約束的「PersonNumber」字段。 – Karl 2011-03-30 14:00:12

「這是一個壞主意？」 - 一般來說，是的。因爲當你需要3,4個人時，會發生什麼？

相反，建立一個多到許多加盟合同的人，ContractPerson，含ContractId間表，PERSONID

來源

2011-03-30 13:14:15

「沒有其他排列組合。」可以更好地表述爲「在這個時間點上沒有其他排列......」我們都知道requiremens需要改變，即使現在它很棒，而這就是它的原因......什麼發生在3個月內的事情發生了變化。與米奇100％協議+1 – Patrick 2011-03-30 13:18:40

我同意米奇的是，所有的事情都是平等的，你描述的情況下更好地與服務M：N關係。

但是，對於「多個FK到同一個表」是否非常糟糕這個一般問題：我不這麼認爲。例如，如果Person和SecondPerson具有根本不同的用途，則應在目的之後命名字段，而不是它們指向的表。所以，而不是PersonID，PersonID_Second，你會叫他們SalesDudeID和ManagerID。

在這種情況下，使用M：N表會更不理想，因爲它不太清楚哪一個是SalesDudeID，哪個是ManagerID。此外，「如果有3或4會發生什麼」這個問題可以被顛倒，而不是表明模式不可擴展，但M：N模式將允許無效數據（如果3和4，如您所說，是非法的）。

再次......我同意米奇對具體問題的看法。我只是讀了這個問題，好像卡爾簡化了用例的清晰性，並且想要談論他可能會或可能不會意味的更普遍的問題。 +1給米奇。

來源

2011-03-30 13:25:58

SQL：關係數據庫設計 - 多FKS給同桌

回答

相關問題