ORM是否会促进数据库非规范化？

Doctrine和Propel都利用单个和具体的表继承来映射对象关系。前者将类树中所有可能的字段映射到单个表，而后者将每个类都映射到特定表，从而在继承层次结构中复制了公共字段。

虽然这有利于ORM设备，但对我来说建议数据库设计不好。这些错误的设计模式是否可以在数据库上执行？

在不知道应用程序正在做什么，数据的形状，性能期望等等的情况下，无法说出特定的数据库设计是否不好。虽然通常将规范化（在某种程度上）视为最佳实践，但出于性能原因对数据库区域进行非规范化是很常见的，因此，好与坏非常容易进行讨论，而没有比大多数人刚开始时拥有更多数据的更多信息。

加上可用于对象到关系映射的许多方法，事情变得更加复杂，因为“最佳”数据库结构将取决于特定的对象模型，继承级别等。

通过采用一种合适的方法，ORM持久性库几乎总是针对任何给定情况生成非最佳的数据库结构，并且将使用某些在给定情况下被视为不好的做法。

您当然可以编写一个标准化的ORM，但是您会看到相当大的性能影响，因为对主表中的每个插入都需要扫描各种查找表以查看值是否存在，它们是否确实获取了键以及是否没有键。不要进行相关插入。

（当您手动执行此操作时，您可以缩短一些操作，因为您知道向他们显示了一个仅包含有效值的下拉菜单，因此您无需进行这些查找，您可以轻松使用它来进行操作为了有效，ORM无法进行此假设，因为它无法控制UI。）

但是您要记住的是，它们并不是针对数据库性能或数据完整性进行优化，而是针对开发速度进行优化。如果数据的特定结构对您很重要，那么您要么需要手工编写对象/ RDBMS映射代码，要么至少对所有可用库进行详细评估，然后选择最能满足您需求的库（如果存在）。

从本质上讲，它取决于需求以及结构良好的数据，数据库性能和开发速度之间的权衡。与许多折衷一样，您无法选择全部三个。

根据经验，切勿对数据建模以满足开发人员的需求（您可以使用Views或Sp，但不能使用Data Model）。

数据模型应基于应用程序的业务规则和性能需求。

我不同意ORM会促进非规范化或错误的数据库设计。实际上，我见过的最糟糕的设计数据库是在没有ORM的情况下完成的。通过简化基于行id的适当关系，而不是根据随机字段的值进行关系，可以促进良好的数据库设计。

可能它不会促进规范化，但是在ORM中，很容易制作表/对象和关系，这几乎也可以看作是促进了规范化。在ORM中创建带有地址的“位置”表并将员工链接到该位置，而不是将地址添加到employee表中并不需要太多工作。但是，如果没有ORM，则将位置分开意味着您每次也要访问该位置时，都需要进行联接。

所以我的回答是：不，我不这么认为。实际上，实际上可能还有其他方法，一个好的ORM会鼓励一个好的数据库设计，至少是关于那些经验不足的人。