为了将来的灵活性，我应该用关联表建模吗？

Question

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

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

以下是两个实现选项：

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

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

你会选择哪种选择?为什么？

Answer 1

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

REmemeber，您以后总是可以更改模型，然后通过接受替换当前子表的子表(重命名)和关联表表，并将它们放在一个名为“当前子表”的视图中，以确保其不会中断。那么您的代码更改就不会那么痛苦了。

Answer 2

很难根据潜在的需求来设计软件。我会坚持实际的要求。这样你就能按时完成了。

而且，如果您有一个多到多以后的实际需求，那么以后再实现。

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

Answer 3

同意塞斯的说法。我们有着和你一样的情况，我们采用了多到多的设计来存储一对多的数据，而将来我们需要存储很多到多的数据。随着时间的推移，它变成了(IMHO)一种可怕的传说，事后看来，许多关系要求都是“个别的”，而且(通常是合理的)快速工作被实施了。现在我们已经到了我们必须建立它的地步了，我们不仅必须按照我们的计划重构这个系统，我们还必须拆解和解释所有的临时传说。