目前我正在做一个项目，其规范不清楚 - 谁不知道。我想知道设计 DB 的最佳开发策略是什么，它迟早会通过额外的表和关系进行扩展。我想包括“可变性”。
我主要关心的是我想应用设计模式(这是一个大学项目)，我想通过选择合适的设计模式来将常量因素与那些改变的因素分开——在我的例子中是 MVC 和一组模型级别的子模式.
然而，当涉及到数据库时，我可能不得不在我的 MVC 方法中重新设计我的模型，因为我的域模型在稍后阶段需要一组不同的类来表示数据库表。我使用 Hibernate 作为 DB 和应用程序之间的抽象层。
你会从一个非常小的数据库开始，只有几个表和关系吗？如果我也想要一个高效的数据库怎么办？我想知道在现实世界中应用了哪些策略。例如，当涉及到不断变化的需求时，利益相关者分析并不是一个充分的规划解决方案。我认为 - 在数据库级别 - 我的设计模式结束。因此，我希望通过明智的策略将违规行为的影响降至最低。
最佳答案
在不清楚的情况下，我更喜欢简约的 DB 设计，以支持目前已知的需求。我的经验是，任何努力变得聪明，为 future 的需求建模都会使模型变得更加复杂。当新的需求出现时，它们往往处于不可预见的领域。针对 future 需求的额外建模不适合新需求，反而使所需的重构更加困难。
由于您已经选择了 Hibernate 来解耦 DB 设计和 OO 模型，我认为坚持使用尽可能简单的 DB 是一个不错的选择。
关于model-view-controller - 设计一个可扩展的数据库模型，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/2754115/