数据库建模或数据库设计：哪个先出现？答案

【问题标题】：Database modelling or database design: Which comes first?数据库建模或数据库设计：哪个先出现？
【发布时间】：2010-12-01 19:36:21
【问题描述】：

我想知道哪个是域实现的常见做法。首先设计需要持久性或数据库模式的业务对象，然后从实体关系图（然后是 ORM poco*'s）生成它？

我将开始一个解决方案，但我想知道哪个是最可取的“模式”。

(*由 NHibernate 提供支持)

【问题讨论】：

【解决方案1】：

两者都是常见的做法，这取决于每个实施者的偏好。正如 duffymo 建议的那样，您应该选择您最了解的人。

不过，您还应该考虑到您处理数据的常规模式是什么。拥有在任何一个中都很好地建模但在性能方面非常昂贵的东西不是一个好的选择。平衡在中间的某个地方。

我个人倾向于更多地关注数据库方面的事情，主要是因为数据库是更难扩展的。在设计数据库时牢记这一点会有所帮助。您不必一定要按照严格的缩放规则进行初始设计，但记住这一点可能会帮助您在以后需要缩放时不要做出等同于射击自己的设计决策。

【讨论】：

【解决方案2】：

取决于您是对象还是关系建模者。偏好取决于您最了解的内容。

我是一个对象人，所以我会说在对象中建模问题，然后从中获取关系模式。

我认为有很多对象无法解决的数据问题（例如，索引、主键和外键、规范化）表明您在完成后仍有一些工作要做。

但是任何有关系的人都会争辩说他们是主要的，应该坐在驾驶座上。

我怀疑这个问题是否会有明确的答案。我不相信应该有。存在真实的对象关系阻抗失配。对象以实例为中心；关系模型是基于集合的。两者都需要仔细考虑。

【讨论】：

我刚刚在 NHibernate in Action 找到了一个很好的文档化答案，这本书是我最近买的。它说，如果您处于从头开始的项目中，那么自上而下的方法是好的。设计实体，装饰它们，然后是数据库。我想我已经被搁置了，所以我会尝试这种方法，但我想我会被 ORMapper 绑定（以防我在接下来的几天里改变主意），不是吗？
@Aggelos - 如果您正确分层应用程序，则不会有将自己绑定到某个 ORM 的风险。人们将他们的应用程序正确分层并不常见，因为正确地做起来有些困难。
+1 表示不匹配，并且索引和规范化不是对象结构固有的——主要是因为不必构建对象来存储和查询（如表中的记录）；但是，关系建模中的键与对象建模中的引用同构（即，可以构造从引用到键的映射以及键到引用的逆映射。像 Hibernate 这样的 OR/M 证明了这一点。）