這是一個數據庫建模問題。我應該使用關聯表爲未來的靈活性建模嗎？
我通常用一個標準的父子表設置模型一對多，我通常使用兩個表之間的關聯表建立多對多模型。在這種情況下，當前的需求需要一對多的關係。但客戶正在談論一些潛在的未來需求，這將需要一個多對多的關係。
因此，這裏有2個實施選項：
事後修改數據庫結構在我們的應用程序中可能會有些痛苦，但我可能會在靈活性的名義下引入不必要的複雜性。
你會選擇哪個選項，爲什麼？
在您做出的設計選擇，坐下來與客戶，詢問他們是未來的many2many要求有多麼嚴重。解釋這將如何改變數據模型以及它將花費多少錢，並且看看他們現在是否願意繼續使用many2many模型。
記住你可以隨時更改模型，然後通過取代子表（已重命名）和關聯表表格來替代當前子表表並將它們放入名爲like的視圖中當前的子表。那麼你的代碼更改就不那麼痛苦了。
同意Seth。我們的情況與您一樣，並採用多對多設計來存儲一對多數據，而在將來我們需要存儲多對多數據時。隨着時間的推移，它突變成（恕我直言）一個可怕的混亂，事後顯示什麼是「個人」的多對多關係要求和（通常合理的原因）快速解決方案實施。現在我們已經到了必須構建它的階段，我們不僅需要按照計劃重構系統，還必須解開並解釋所有臨時問題。
問：顧問想要使用一個連接表時，有多對多的關係表 2之間。 ......他們也想用完全相同的概念來表示一對多（父母/子女）關係。他們說，使用今天的編程工具時，擁有第三張表格有很多好處。
對我來說，似乎不得不維護三個表格及其索引，而不僅僅是 2，這是不必要的，並增加了開銷。
答：對於許多人來說，你必須使用關聯表，因爲他們是已知的。這是 標準。
對於一對多的人來說 - 他們是「抽着點有趣的東西」。
它不僅會遭受你描述的問題，而且它使得它無限難以維持1對多的關係 - 你需要關聯表上的另一個附加唯一索引 以強制執行一個「湖。
您在每個incurr額外IO的開銷，每加入，以及 - 高達：
你可以在每個加入的行中名義上添加2-4個IO。沒原因。
我從來沒有聽說過任何人將此作爲標準操作程序在我的 生活中使用過。這聽起來像一個非常糟糕的主意。
示例簽證申請人：簽證部門接受許多申請人。如果申請人申請一種簽證，他/她不能申請多種類型的簽證。
這種關係是一對多（Visa-Applicants） - 簽證表（visa_type），申請表（申請人ID，簽證類型）。
如果我們將規則修改爲多對多，即申請人可以申請多種簽證，我們有 - 簽證表（與以前相同），申請表（申請人ID），申請人簽證 - 表（申請人ID，簽證ID）。
因此，破壞程度是（如果/當該商業規則變化發生在未來）：申請人.visa_type列必須遷移到申請人 - 簽證表。您公開此信息的網頁也會被中斷（即強制更改）。所以您的數據庫更改將伴隨應用程序更改。
總之，我想知道它是否值得在數據庫中構建抽象，如果這不符合應用程序代碼的話。意思是，如果當商業規則發生變化，我會願意一起解決數據庫層和網絡層的變化。 有人在數據庫級查看多對多關係可能會誤認爲目前正在實現這樣的功能。
選項1.