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

Question

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

对于那些处理过这个问题的人来说,你的理念是什么？当然,并非每个实体都将1:1映射到数据库表.但是,对于那些那样做的人,你是如何处理这个的？IOW,首先是数据库表,然后是相应的实体或实体,然后是数据库表来持久化它？

谢谢.

Answer 1

"实体,然后是一个数据库表来保持它"

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

该实体的数据库表示(如平面文件表示或GUI表示)只是该实体的方便表示.

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

数据库不太重要.

实体定义是核心和必要的.

Answer 2

您的数据库可能会比您今天构建的任何应用程序都长寿。所有性能和可扩展性都将由您的数据库模式驱动。健全的数据库模型是构建任何应用程序的基础，我想说这是您应该在设计和测试上投入最多精力的地方，因为它将带来最大的好处。

话虽这么说，当然您的应用程序更喜欢操作领域实体，而操作由关系理论驱动的非自然实体而不是业务实体只会使事情变得复杂。我的观点是，ORM 的作用就是尽可能地匹配两者。但是，每当出现不可避免的冲突时，应该由性能和可扩展性的驱动因素（数据库模式）来决定优先权。