我应该使用关联表建模以确保未来的灵活性吗？

Question

这是一个数据库建模问题。

我通常使用标准的父子表设置建模一对多，我通常使用两个表之间的关联表来建模多对多。在这种情况下，当前要求需要一对多的关系。但客户正在讨论一些可能需要多对多关系的潜在未来需求。

所以这里有两个实现选项：

1. 将数据库建模为一对多以满足当前要求。如果未来的需求需要多对多，那么我需要更改数据库结构和应用程序代码。
2. 将数据库建模为多对多，并使应用程序代码将数据限制为一对多。如果未来的需求需要多对多，那么我只需要更改应用程序代码。

在我们的应用程序之后更改数据库结构可能会有点痛苦，但我可能会以灵活性的名义引入不必要的复杂性。

您会选择哪个选项？为什么？

Answer 1

根据潜在要求设计软件非常困难。我坚持实际要求。这样你就可以按时完成。

而且，如果您之后有多对多的实际要求，那么implement it later。

只是我的意见..另一方面，我按小时收到报酬。

Answer 2

同意赛斯的观点。我们遇到了与您相同的情况，并采用多对多设计来存储一对多数据，而未来的日期需要存储多对多。随着时间的推移，它变成了（恕我直言）一个可怕的kludge，因为后见之明显示出“个人”的多对多关系要求，并且（出于一般合理的原因）实施了快速解决方案。现在我们已经达到了我们必须建立它的程度，我们不仅要按照我们的计划重构系统，我们还必须解开并解释所有临时的克制。

Answer 3

在做出设计选择之前，请与客户坐下来，询问他们对未来很多要求的认真态度。解释这将如何改变数据模型以及它将花费多少，看看他们现在是否希望继续使用many2many模型。

请记住，您以后可以随时更改模型，然后通过使用子表（重命名）和关联表表替换当前子表表并将它们放在名为“目前的子表。那么你的代码更改就不那么痛苦了。

Answer 4

来自this question on AskTom：

问：顾问希望在有多对多关系时使用联接表 两张桌子之间。 ......他们还希望使用完全相同的概念来表示1对多（父/子）关系。他们说使用今天的编程工具时，拥有第三个表有许多好处。

对我而言，似乎必须维护三个表及其索引，而不仅仅是 2，是不必要的，并增加了开销。

答：对于许多人而言，您必须使用已知的关联表。这是 标准。

对于一对多 - 他们“吸烟有趣”。

它不仅会受到您描述的问题的困扰，而且会使它变得无比困难 保持1对多关系 - 你需要另一个额外的唯一索引 在关联表上，以强制执行一个人。

您在每个连接中都会产生额外的IO开销 - 以及：

• n IO用于索引访问关联表
• 1 IO来读取关联表

您可以在每个加入的行中名义上添加2-4个IO。无缘无故。

我以前从未听说过有人将此作为标准操作程序使用 生活。这听起来真的很糟糕。

Answer 5

签证申请人的一个例子：签发部门接受许多申请人。如果申请人申请签证，他/她不能申请多种签证。

这种关系是一对多（签证申请人） - 签证表（visa_type），申请人表（申请人身份证，签证型）。

如果我们将规则更改为多对多，即申请人可以申请多种签证，我们有 - 签证表（与以前相同），申请人表（申请人身份证），申请人签证 - 表（申请人身份证，签证身份）。

因此，中断的程度是（如果/将来该商业规则发生变化）：申请人.visa_type列必须迁移到申请人签证表。您公开此信息的网页也将被中断（即强制更改）。因此，您的数据库更改将伴随应用程序更改。

总之，我想知道它是否值得在数据库中构建抽象，如果这不是与应用程序代码相结合的话。意思是，如果biz规则发生变化，我愿意一起解决DB层和Web层的变化。 在数据库级别中查看多对多关系的人可能会误以为当前正在实现这样的功能。

Answer 6

选项1。

• KISS
• YAGNI