这是一个数据库建模问题。
我通常使用标准的父子表设置来建模一对多，并且我通常使用两个表之间的关联表来建模多对多。在这种情况下，当前要求需要一对多关系。但客户正在谈论一些可能需要多对多关系的未来需求。
所以这里有 2 个实现选项：
事后更改数据库结构可能会给我们的应用程序带来一些麻烦，但我可能会以灵活性的名义引入不必要的复杂性。
你会选择哪个选项，为什么？
【问题讨论】：
根据潜在需求设计软件非常困难。我会坚持实际要求。这样你就可以按时完成了。
而且，如果您以后有多对多的实际需求，那么implement it later。
只是我的意见.. 另一方面，我按小时获得报酬。
【讨论】：
在您做出设计选择之前，请与客户坐下来，询问他们对未来多对多需求的重视程度。解释这将如何改变以后的数据模型以及成本是多少，看看他们现在是否想继续使用 many2many 模型。
请记住，您以后可以随时更改模型，然后通过获取替换当前子表的子表（重命名）和关联表并将它们放在一个名为当前子表。这样你的代码更改就不会那么痛苦了。
【讨论】：
同意赛斯。我们和你有同样的情况，并采用多对多设计来存储一对多数据，以应对未来我们需要存储多对多的日期。随着时间的推移，它变成了（恕我直言）一个可怕的杂物，事后看来是“个人”的多对多关系要求出现了，并且（出于普遍合理的原因）实施了快速的解决方法。既然我们已经到了必须构建它的地步，我们不仅要按照我们的计划重构系统，我们还必须解开并解决所有临时问题。
【讨论】：
问：当存在多对多关系时，顾问想使用连接表 2张桌子之间。 ...他们还想使用完全相同的概念来表示一对多（父/子）关系。他们说，在使用当今的编程工具时，拥有第三张表有很多好处。
对我来说，似乎必须维护三个表及其索引，而不是仅仅 2，是不必要的，并且会增加开销。
答：对于多对多，您必须使用已知的关联表。这是 标准。
对于一对多来说——他们在“抽一些有趣的东西”。
它不仅会遇到您所描述的问题，而且会使它变得无限困难 保持一对多的关系——你需要另一个额外的唯一索引 在关联表上以强制执行一体性。
您还会在每次连接中产生额外的 IO 开销——多达：
您可以名义上向加入的每一行添加 2-4 个 IO。无缘无故。
在我之前从未听说有人将此作为标准操作程序 生活。这听起来是个非常糟糕的主意。
【讨论】：
签证申请人示例：签证签发部门接受许多申请人。如果申请人申请一种签证，他/她不能同时申请多种签证。
这种关系是一对多的（Visa-Applicants）——visa-table（visa_type），applicant-table（applicant-id，visa-type）。
如果我们把规则改成多对多，即申请人可以申请多种签证，我们就有- visa-table（和之前一样），applicant-table（applicant-id），applicant-visa-表（申请人 ID、签证 ID）。
所以中断的程度是（如果/当该商业规则在未来发生变化时）：申请人.visa_type 列必须迁移到申请人签证表。您公开此信息的网页也将被破坏（即强制更改）。因此，您的数据库更改将伴随应用程序更改。
总而言之，我想知道它是否值得在数据库中构建抽象，如果这不与应用程序代码齐头并进。这意味着，如果 biz 规则发生变化，我愿意一起解决 DB 层和 Web 层的变化。 在 DB 级别查看多对多关系的人可能会误以为当前已实现了这样的功能。
【讨论】：
选项 1。
【讨论】：