【发布时间】：2010-02-14 02:37:02
【问题描述】：
我们的开发小组就实体的组合是否应该驱动数据库设计，还是应该由数据库设计驱动实体的组合进行了相当多的讨论。
对于那些处理过这个问题的人，您的理念是什么？当然，并不是每个实体都 1:1 映射到数据库表。但是，对于那些这样做的人，您是如何处理的？ IOW，哪个先来数据库表再对应实体还是先实体再数据库表持久化呢？
谢谢。
【问题讨论】：
标签： c# sql-server linq-to-sql orm entity
【发布时间】：2010-02-14 02:37:02
【问题描述】：
“实体，然后是一个数据库表来持久化它”
实体是您的程序操作的对象。这就是正在处理的内容的本质。
该实体的数据库表示（如平面文件表示或 GUI 表示）只是实体的方便表示。
当涉及到关系数据库特别不擅长的某些事情时，您可能需要考虑一下 DB 表示。例如，多对多关系需要引入一个额外的表，因为数据库具有您的对象模型所没有的限制。您可能有一些实体设计注意事项来解决这个问题，但这些都是很容易理解的。
数据库不太重要。
实体定义是核心和必要的。
【讨论】：
-
有趣的观点。对此的意见似乎无处不在。 ORM 之父 Raymond Chen 博士（LLBLGen 正是在此基础上构建的）持相反的观点。数据库驱动实体。见：wagnerblog.com/2009/10/…
-
@Randy Minder：逻辑很简单。应用程序实际执行实际系统的实际工作。其他一切都是呈现或持久性。陈的参考资料很难追查。之前的 wagnerblog 条目引用了 Peter Chen。 Raymond Chen 的博客并没有过多提及 ORM。实际上，对象很重要。数据库只是持久性。
-
我也同意这个答案。另一个重要方面是数据库模式仅包含与预期实体操作相关的一些方面，即无论如何您都需要额外的注释来描述诸如延迟加载、关联行为等之类的事情。数据库通常比应用程序寿命更长的事实并不意味着您必须首先设计它，如果该工具允许简单地生成它。因此，我还将数据库视为特定存储表示。
-
数据库的能力不仅仅是持久性。可以实施业务规则，可以限制数据……好处意味着可以减轻应用程序的开销，这无法与数据库处理竞争。将业务规则集中到数据库使使用其他语言进行开发变得更加容易 - 无需重新发明。
-
@OMG Ponies：某些数据库可能能够将一些应用程序逻辑推入数据库本身。有人认为这是一件好事。它使您的应用程序混乱（有些部分是真实的代码，有些部分是存储过程）。它也使事情通常变慢。尝试基准测试。存储过程本身并不快；它们通常是洗涤物。围绕模型对象进行清晰的设计。仅当您能够证明它们提高了性能时才实施 SP。
您的数据库可能会比您今天构建的任何应用程序寿命更长。所有性能和可扩展性都将由您的数据库模式驱动。完善的数据库模型是构建任何应用程序的基础，我想说的是，您应该在设计和测试方面投入最多的精力，因为它会带来最大的好处。
话虽如此，您的应用程序当然更喜欢操纵领域实体，而操纵由关系理论驱动的非自然实体而不是业务实体只会使事情复杂化。我的观点是，ORM的作用就是尽可能地匹配这两者。但是，无论何时出现不可避免的冲突，都应该由您的性能和可扩展性的驱动因素来给予优先权：数据库模式。
【讨论】：
-
@Remus - 我认为这是一个非常好的观点，而且我还没有真正考虑过。数据库及其中的数据可能会比将数据持久保存到其中的初始应用程序寿命更长。它可能会以多种方式使用，而不仅仅是将其数据保存在那里的应用程序。
我会说你构建了你的逻辑数据模型，并构建了与之对应的数据库和对象。
其实我会质疑数据库表和对应实体不能对应的假设。我很少见过他们真的做不到的情况（如果您从头开始构建应用程序）。另外，我想说的是，每次对象模型和数据库模式出现分歧时，都会带来很多问题。
我再次想到，如果你让它们始终匹配，一切都会变得更简单，无论这可能是异端。
【讨论】：
-
我还没有看到链接（多对多）表的直接翻译。通常，它们被实现为主对象的 Vectors/ArrayLists 属性，而不是它们自己的类。
-
@OMG Ponies：关联表没有直接转换，因为关联表不是实体模型的一流部分。额外的链接表是使关系模型表示更复杂的对象关系的标准技巧的一部分。
-
@S.Lott：它们被称为“关系”数据库，而不是“面向对象”。链接表不是业务实体，但映射到 Vector/ArrayList/Collection/etc 仍然是等效的对象。