类设计与Db设计（ER图）

Question

在系统开发的设计阶段，类设计是否应该规定db的设计，或者db设计是否应该规定类设计。我意识到有几种情况，其中一种或另一种已经存在，并且必须围绕现有设计另一种情况。但是说如果你能从头开始，这是一种更好的方法吗？我更倾向于类设计，然后是DB，但是想要对这个想法有所了解。哪些扩展问题需要考虑？实施问题？

Answer 1

每当由我决定时，我几乎总是从数据库设计开始。

如果您的程序设计不正确或设计不当，您最好总是丢掉一个程序并重新编写。但是，如果您的数据库设计不正确或设计不当，那么当您意识到自己遇到问题时，可能会有数百个使用该数据库的程序。更改数据库意味着至少要研究使用它的每个程序，严重的数据库设计更改可能意味着要大量修改使用数据库的每个程序。因此，对于您的数据库来说，精心设计比设计精心设计的程序更重要。

Answer 2

非常依赖应用程序，我会说。如果您的应用程序主要关注数据，那么您应该优先于应用程序设计数据库;如果您的应用程序主要是关于业务逻辑或计算，您可能希望支持应用程序设计。

另一个考虑因素是应用程序的使用寿命和范围 - 正如Jay所说，不止一个应用程序使用同一个数据库并不罕见。虽然我实际上建议这是为数据库提供基于服务或消息的接口的原因 - 我认为您不希望允许多个应用程序直接访问数据。在这种情况下，我认为您将设计工作重点放在服务层上。

您还可以考虑将设计映射到业务领域 - 理想情况下，您希望软件反映业务概念（请查看Evans的“域驱动设计”）。在使用对象技术而不是实体关系模型时，这通常 - 但并非总是 - 更容易（经典问题是如何将继承映射到数据库模型）。

最后，考虑团队的技能和倾向是很重要的 - 拥有一帮数据库大师设计对象模型通常会导致陡峭的学习曲线（反之亦然）。

Answer 3

  

班级设计是否应该决定   设计db，还是应该db   设计决定班级设计。

我不确定是否指示另一个的设计。 听写意味着紧密耦合，这通常是一件坏事。

数据库设计假设其他程序将访问数据库。数据库设计的一个重要部分是选择好的表名，列名和完整性约束。所有这些都是数据库公共接口的一部分。 （所有这些都与规范化相关，这是一个应用程序开发缺乏的基于数学的过程。这是观察，而不是批评。）

更改设计糟糕的公共界面真的非常昂贵。

Answer 4

您的数据库应该经过深思熟虑，但应用程序和数据库设计都不会对另一个产生重大影响。您的应用程序应该与数据库无关。要存储应用程序数据，您应该依赖于一个层，该层提供从域对象到数据库表的必要转换。