ORM - 数据库架构是驱动实体组合还是反之亦然？

Question

我们的开发小组已经就实体的构成是否应该推动数据库设计，或者数据库设计是否应该推动实体的构成进行了相当多的讨论。

对于那些处理过这个的人来说，你的哲学是什么？当然，并非每个实体都将1：1映射到数据库表。但是，对于那些那样做的人，你是如何处理这个的？ IOW，首先是数据库表，然后是相应的实体或实体，然后是数据库表来保存它？

感谢。

Answer 1

“实体，然后是数据库表来保持它”

实体是您的程序操作的。这就是正在处理的内容。

该实体的数据库表示（如平面文件表示或GUI表示）只是该实体的方便表示。

当谈到关系数据库特别糟糕的某些事情时，您可能需要考虑一下DB表示。例如，多对多关系需要引入额外的表，因为数据库具有对象模型没有的限制。您可能需要一些实体设计考虑因素来解决这个问题，但这些考虑因素很少且很容易理解。

数据库不太重要。

实体定义是核心且必不可少的。

Answer 2

您的数据库可能比您今天构建的任何应用程序都要长。所有性能和可伸缩性都将由您的数据库架构驱动。一个健全的数据库模型是构建任何应用程序的基础，我想说你应该在设计和测试上投入大量精力，因为它将带来最大的好处。

话虽如此，当然你的应用程序更愿意操纵域实体，并且操纵由关系理论驱动的非自然实体而不是商业实体会使事情复杂化。我的观点是，ORM的作用是尽可能地匹配两者。但是，只要出现不可避免的冲突，就应该通过性能和可扩展性的驱动因素给出通路：数据库架构。

Answer 3

我会说你构建你的逻辑数据模型，并构建与之对应的数据库和对象。

实际上，我会质疑数据库表和相应实体无法对应的假设。我很少见到他们真的不能解决的情况（如果你是从头开始构建一个应用程序）。另外，我会说每次对象模型和数据库模式分歧时，都会引入很多问题。

我回过头来想到，如果你让它们始终匹配，那么一切都会变得更加简单，不管它是不是异端。