争论：OODBMS有时要比ORM方案略胜一筹？

作者 Ryan Slobojan译者 高昂 发布于 2007年6月19日 下午7时0分

社区

Java

主题

数据访问

标签

db4o

在ODBMS.org站点一篇刚发布的文章中，作者Ted Neward详细阐述了自己关于对象关系映射（Object/Relational Mapping，ORM）的看法，Ted认为如果不分场合地滥用ORM，就如同计算机领域的越南战争一样，会给项目带来不良的影响。Ted在文中阐述的主要观点是，面向对象数据库管理系统（Object-oriented Database Management Systems，OODBMS）在某些应用场合，将比关系型数据库管理系统（Relational Database Management Systems，RDBMS）有更多的优势，比如说：

“在相互不匹配的应用中，就像以前那些建立在大型数据库基础之上的小型Web应用一样，使用单一的用户接口来访问单一数据库，或是使用技术先进的网络服务来实现。然而，如果所有的交互操作通过用户接口或服务接口完成，并且从不会对数据库自身产生影响，那么就可以使得数据持久层真正服务于用户所关心的业务。上述情况下，由于目前仍然没有可以将两种不同语言（比如Java/C#和SQL数据定义语言DDL）很好融合的实体定义，那么就可以在面向对象数据库后端，定义并实现一个面向应用的富领域模型。”

Ted同时也就面向对象数据库试图要解决的双重模式问题阐述了自己的观点：

“[...]在传统的对象关系世界里，存在两套实体定义：一个是由编程语言自身定义，而另一个使用SQL DDL关系模型定义。这将会产生一种先天的不足，因为在系统发展和改进的同时，两种实体定义都需要保持最新的状态，或者通过强制同步的机制（这通常被看作是使用代码生成的策略，或是通过从模式到类的转换以及其他方法完成），或者将两者分别编辑和比较并且在需要时手工调整映射。这为两种实现都带来了压力，并且常常使得开发者由于需要保持两种模型的单一程度，做出一定量的额外工作，来保证两者彼此之间的同步。

此外，在面向对象数据库管理系统中，实际上类定义是唯一的模式表现，意味着不会有双重模式的问题存在；域模型不需要被限制在存储定义之中，并且如果只为了支持富领域模型的存储，那么数据存储定义不需要使用不常见的形式来表示。”

一部分人对此观点表示赞同，比如Andrew McVeigh这样评论道：

“面向对象 --> 存储复杂的图形，在对象间快速索引和定位，且较少出现匹配错误。

关系型数据库 --> 数据独立性，适用于复杂的报表，更佳的DDL模式管理方式。

如果使用关系型数据库存储CAD系统的图表，或是使用面向对象数据库来为数据生成报表，则必定会为业务带来麻烦。”

然而，也有人反对这样的观点，特别是以Gavin King为代表，他撰写了为关系型数据库的角色进行辩护的文章。文中列出了他的看法，简单可以总结为如下几点：

• 遗留数据需要对象关系映射ORM——ORM是处理现有模式或支持遗留数据的唯一方式，所以没有道理用其他的方式替换ORM。
• ORM方便使用者操作数据库——如果使用者没有向后兼容的需求，ORM可以为使用者生成映射和数据库模式。
• 数据比应用更为持久——由于数据总是比产生数据的业务应用存在的时间更持久，所以需要有实体关系映射机制。
• 面向对象数据库不利于保持兼容性——由于用户可以在数据库中存储强类型的对象，OODBMS很难使用多重开发语言，反之在关系型数据库中的单一字符串和数字可以在各种语言下进行映射。
• 面向对象数据库还远不成熟——由于比起关系型数据库，OODBMS还远不成熟，所以在主流的数据库管理系统中还很难见到OODBMS的身影。
• 面向对象数据库的评价标准还存在缺陷——面向对象数据库系统或是作为应用运行在相同进程之中，或是作为结果以不可拓展的方式存在，在小型的应用中这种方式可以接受，但是在大型应用中表现并不理想。对象关系映射由于其健壮的设计影响了实现效率，一旦面向对象数据库合并了健壮成熟的要素集，将会达到同样的速度。

特别是，Gavin说道：

“可以明确的是，由于访问遗留数据的需求，除非已经存在相同的实现，使用对象关系映射技术不会引入映射或双重定义的问题。如果用户打算“存入数据库中一些对象”，将不需要编写单一的映射注释。所以从这一点来说，对于任意的用例，ORM至少是与对象数据库的实现方式同样出色，并且对于处理对象数据库没有涉及的其他用例也表现良好。”

Gavin进一步解释：

如果你认为相关技术也用作持久化应用的状态，那么你大概是想错了。关系模型的价值在于它是建立在同等的基础之上。任何一种程序设计语言都具备自身独特的价值。关系数据库是一系列技术的综合，而并非只是一种数据持久化的技术。技术的综合是非常重要的，这也是为何我们为技术所纠缠的原因。

同时这也致使Ted Neward对此进行很长的回复：

“何时一种工具可以解决所有的问题？这自然有相应的理由，如果仅是出于“我们一直以来都是在使用关系型数据库”这样的理由，而认为类似OODBMS或HODBMS（Hierarchically-Oriented Database System）这样的数据库不应该使用，那将必然是一个错误的想法。”

Ted也就Gavin的观点进行了反驳，就双重模式的问题对Gavin的观点评论道：

“抱歉Gavin，事实是这样的，你所言的观点是并将一直是我们之间意见的分歧之处，同时也是你和在研讨会中听到我发言以及一同讨论技术约定与分类的广大开发者之间的分歧之处。对于单一的数据表到函数类的映射，你的观点没有错误，因为实现方式较为简单。然而这仍旧是个双重模式的问题，因为你现在同时面对两种相互矛盾的技术，分别是数据库模式和对象模型，所以不得不只选择一种来接受。到目前为止，也许你曾参与过的项目中开发者都同时定义了两种模型，所以并没有出现什么问题，但如果是在面向企业级的解决方案中，数据库模式常常由DBA们来管理并在项目中设定，所以你将无法像更改对象模型那样灵活方便的操作和重构数据库模式。”

这场争论看似才刚刚开始——您为何不就上述观点也发表自己的评论呢？

查看英文原文：Debate: ODBMS sometimes a better alternative to O/R Mapping?

• 更早的 >