设计可扩展的数据库模型

Question

目前我正在做一个规格不明确的项目 - 好吧谁没有。我想知道设计数据库的最佳开发策略是什么，迟早会扩展其他表和关系。我想要包括“可变性”。

我主要担心的是我想应用设计模式（这是一个大学项目），我想通过选择合适的设计模式将常数因素与那些因素分开 - 在我的案例中是MVC和一组子模式在模型层面。 然而，当涉及到DB时，我可能不得不在我的MVC方法中重新设计我的模型，因为我的域模型在稍后阶段需要一组表示DB表的不同类。我使用Hibernate作为数据库和应用程序之间的抽象层。

你会从一个非常小的数据库开始，只是几个表和关系？如果我想要一个高效的数据库怎么办？我想知道在现实世界中应用了哪些策略。例如，在改变需求时，利益相关者分析并不是一个充分的规划解决方案。我认为 - 在数据库级别 - 我的设计模式结束了。因此，我希望通过智能策略将影响降到最低点。

Answer 1

在不清楚的情况下，我更喜欢简约的数据库设计，支持现在已知的需求。我的经验是，任何聪明的努力，为未来需求建模都会使模型更加复杂。当新的需求出现时，它们往往处于不可预见的领域。针对未来需求的额外建模不符合新的需求，而是使得所需的重构更加困难。

由于您已经选择了Hibernate来分离数据库设计和OO模型，我认为坚持使用尽可能简单的数据库是一个不错的选择。

Answer 2

“目前我正在做一个规格不明确的项目”

鉴于'database'标签，我假设您在数据库上下文中询问此问题。

请记住，数据库是一组 ASSACTTIONS OF FACT （大写意图）。

如果不清楚您的用户想要由数据库注册什么样的“事实断言”，那么您根本无法定义数据库的（结构）。

首先尝试清除所有不清楚的内容，然后您将帮助自己和用户。

Answer 3

在一个简单的答案中：BE MINIMALISTIC。

尝试找出主要实体。不要担心属性，稍后您将填写它们。然后，创建实体之间的关系。使用你最喜欢的ORM（Hibernate？）创建一个测试应用程序，构建一些单元测试，并且你有最小的数据库操作。 ：）

Answer 4

您所描述的几乎是每个项目的典型内容。但是你可以做一些事情。

尝试隔离问题域的概念（而不是它们的实现）。请记住：扩展数据模型几乎总是很容易（添加新表，新列等），但更改数据模型很困难，需要数据迁移。

我提倡使用敏捷开发流程：仅实现您现在所需的内容，但请确保在建模之前了解完整的问题。

在开始破解代码之前，您应该检查的另一件事是您选择的基础设施是否合适。当您想要经常更改模式时使用关系数据库通常是不匹配的。文档数据库是无模式的，因此更灵活。我认为您应该使用关系数据库进行评估，这对您的应用程序来说非常合适。

Answer 5

没有任何项目始于完全已知和固定的要求。使用敏捷，迭代的方法进行数据库设计，以便在开发过程中适应变化。

所有数据库设计都是可扩展的，并且在其生命周期内可能会发生变化。不要试图避免改变。只需确保您拥有合适的人员和流程，以便在发生变更时有效地管理变更。