(来源：http://www.ccidnet.com)
一、概述
就象关系数据库一样，市场上有许多面向对象的数据库（Object-Oriented Database，OODB）可供选择。然而，OODB在价格、功能、特色和体系上没有什么统一的标准。本文将帮助你理解各种OODB系统之间的一些差别，在为应用选择合适的OODB时，帮助你缩小挑选的范围。
根据标准的不同，我用于评估这些产品的参考资料也是五花八门。在大多数情况下，本文的评价以个人经验和看法为基础；另外一些细节直接从评测软件或供应商提供的数据资料获得。在作出选择之前，务必针对你的应用进行全面的测试。毕竟，你我看法可能有所不同。
我们将要分析的四种OODB产品是ObjectStore、Versant Developer Suite、Poet FastObjects和Objectivity。每一种产品将从以下几个方面进行评估：
价格和许可
顺从性
兼容性
特色
性能
可伸缩性和可用性
二、价格和许可
工程成本包括两个方面：初始成本和维护费用。初始成本往往在评估中起支配作用，但象年度支持、联机讨论、新手培训等问题都应该成为产品成本的考虑因素。即使和它的竞争者大型RDBMS相比，OODB的价格通常显得很昂贵。
标准
考虑…
评估软件
可免费下载的、全功能的试用软件。
开发版许可价格
低价格，以用户数量为基础的许可。
产品许可价格
低价格，按照CPU数量为单位的许可，低廉的年度维护费用。
联机支持
负责的技术支持人员，大量有用的技术说明、示范和论坛。
活跃的用户社团
大量的热心用户，新闻组里丰富有益的活动，非官方网站的支持。
三、顺从性
和关系数据库相比，OODB一般对顺从标准的要求不是那么严格。大多数OODB都用自己独特的方法实现各种特色功能。由于还没有明确的标准评价OODB，所以对象数据库管理组织（Object Database Management Group，ODMG）的标准是当前最好的准绳。但各个OODB各自为政却带来了一些麻烦，要找出一个完全顺从ODMG 2.0或3.0规范的OODB产品很困难（与已经有一年历史的3.0规范相比，2.0规范是一个相当宽松和不完善的规范）。也许在不远的将来，我们将用Java Data Object（JDO）规范评价Java OODB。
标准
考虑…
对“对象定义语言”（ODL）的顺从
完全遵从ODMG 3.0规范有关对象定义的规范。
对“对象查询语言”（OQL）的顺从
完全遵从ODMG 3.0规范有关查询的规范。
对Java的顺从性
完全遵从ODMG 3.0规范意味着正确实现Java API/绑定。
对C++的顺从性
完全遵从ODMG 3.0规范意味着正确实现C++ API。
对Smalltalk的顺从性
完全遵从ODMG 3.0规范（如果你的系统不太可能用到Smalltalk，那么这只是一个可选的标准）。
四、兼容性
无论是语言还是平台，工程对可伸缩性的要求会日益增加。OODB不应该在任何一方面影响这种可伸缩性。然而，平台支持的代价很昂贵，它要求进行广泛的测试和大量的文档说明。因此，一些供应商的产品只支持数量很少的平台。要找出一个和各种主流OO语言（如C++、Java、Smalltalk）紧密结合的方案是相当困难的。
标准
考虑…
支持的平台
广泛的平台支持——我总是考虑三个关键的平台：Linux，Win2000，和Solaris。你优先考虑的平台可能有所不同。
Java集成
广泛的JDK支持，紧紧跟踪最新的JDK规范。
C++集成
广泛的编译器支持
持久类的特殊化
避免紧密结合——寻找那些不要求修改代码中持久类的数据库。这是一种与偏好有关的选择，所以你应该认真研究处理后扩展和扩展/实现方式相比的优缺点。
可嵌入的版本
只占用少量的磁盘空间、RAM；具有取消一些非核心功能的能力。
五、特色
每一种数据库方案都有自己的一些独特的功能。下面我特别指出一些核心功能，因为这些功能对于开发工程来说具有很高的价值：
标准
考虑…
数据库浏览
管理数据库、修改内容、更新模式和生成内容报表的能力。
客户端缓冲
改善“热点”数据库响应速度的能力；在确保对象同步的前提下，使得对数据库的提取操作减到最少。
数据库安全
用户、用户组访问控制，最好在对象（如果不是容器的话）的层次上进行。
XML支持
无缝地从数据库提取、向数据库插入XML的工具。
IDE集成
和TogetherSoft之类提高开发效率的环境集成能够提高开发效率。
六、性能
在性能的某些方面，OODB占有优势；但在其他方面，OODB又有所不足。在这里提供每一种产品详细的性能测试数据显得过于冗长，但理解可能影响性能的体系和功能方面的局限是很重要的。
标准
考虑…
加锁策略
应用-对象级的加锁机制能够带来很大的方便，但页面级的加锁机制在某些条件下能够带来性能上的飞跃。
负载平衡
透明地分布数据库、调用远程服务器上的方法、在并发线程/访问之间共享对象的能力。
最大的数据库大小
越大越好。
事务支持
检查点：由多个线程共享一个事务，一个线程占用多个事务，嵌套事务；当某个给定产品的实现影响了你的应用时，确保你自己理解了结合客户端缓冲时客户端/服务器端同步的工作机制。
有关查询/性能的信息
提取这些信息的能力，它能够帮助你找出性能瓶颈；OODB提供的优化和调整选项通常要比RDB少，但一些帮你提取性能信息和解释查询执行计划的工具仍很有用。
七、可伸缩性和可用性
虽然并非每一个工程都要求有企业级的恢复、可用性、可伸缩性功能，了解你所选择的OODB方案能够随着工程一起发展而提供这方面的能力是值得的。
标准
考虑…
失败转移
主服务器出现问题时，透明地切换到冗余数据库。
负载平衡
把负载分布到冗余服务器、把对象分割到多个服务器、同步多个客户端对象缓冲之间数据视图的能力。
复制和增量备份
无缝地复制数据，支持负载平衡和恢复的能力。
专用的查询引擎（Ad hoc query engine）
丰富的查询语言，允许对数据的快速访问；理想情况下，它应该能够跨越没有直接关联的对象连接数据。
八、产品评论
下面，我按照前文提出的标准评估以下产品：
请参考Cetus OODB area，那里有一个相当新的OODB供应商清单。
标准
ObjectStore
Versant Developer Suite
Poet
Objectivity
背景信息
供应商
产品主页
技术参考[29]
PDF overview 或 specific data sheets
版本
6.0
6.0
t7 8.0[16]
6.0
价格和许可
试用版本
30天试用[1]
60天试用
功能限制
90天试用
许可费用
[2]
[2]
[2]
[2]
联机支持
尚可[3][9]
尚可[9]
好[19]
很好
用户社团[23]
中等[4]
中等
较小
中等
顺从性
ODL顺从性
N
N
N
不完整的2.0/3.0支持
OQL顺从性
N
N[10]
ODMG 3.0[17]
N
Java接口
遵从ODMG 3.0
ODMG 3.0
ODMG 3.0
ODMG 3.0
C++接口
支持
ODMG 3.0
N/A
不完整的2.0/3.0支持
Smalltalk接口
N/A
N/A
N/A
ODMG 3.0
兼容性
支持的Unix操作系统
Linux，Solaris，HP-UX，IRIX，AIX，Tru64 [ref]
Linux，Solaris，HP-UX，IRIX，SGI，Tru64 [ref]
Linux，Solaris，HP-UX[ref]
Linux，Solaris，HP-UX，IRIX，AIX，Tru64 [ref]
支持的Windows操作系统
98，NT4，2000 [ref]
NT4，2000 [ref]
98，NT4，2000 [ref]
98，NT4，2000 [ref]
JDK要求
1.0，1.1–1.3[22]
1.2，1.3
1.1-1.3
1.22，1.3
持久类的特殊化
N[5]
N[5]
N[5]
Y[24]
可嵌入的版本
Y
N
Y[18]
N
功能
数据库浏览器
Y
Y
Y
Y
客户端缓冲
Y
Y
Y
Y
数据库安全
数据库或者段的用户/组控制
数据库的用户控制[14]
特定类和数据库的用户/组控制
数据库的用户控制
XML支持
Y
Y[15]
部分[20]
部分[20]
性能
加锁策略
数据库，页，或者对象
对象级
对象级
容器级[25]
最大的数据库大小[7]
数百个GB？
数十个GB到数百个GB？[12]
？
根据报告，它达到了TB级
事务支持
死锁检测，MVCC [8]
分布式事务管理（类似于MVCC的概念）
检查点，共享或并行的事务，嵌套事务
检查点，死锁检测，共享或并行的事务
提供有关查询/性能的信息
Y
N[13]
N
N[26]
可伸缩性
失败转移（failover）
Y
Y
Y
可选[27]
负载平衡
部分[6]
部分[11]
部分[21]
可选[27]
复制和增量备份
Y
Y
Y
可选[27]
专门的查询引擎（Ad hoc query engine）
没有OQL。使用集合和查询对象
Y[10]
Y (OQL)
Y[28]
■ 结束语
我希望自己还没有给人以OODB狂热鼓吹者的印象——对于我所使用的大多数应用，我认为应用OODB带有一定的风险。然而，一旦你理解并熟悉了OODB，它们可以成为很方便的工具。我个人比较看好Poet和ObjectStore，但我觉得它们都很有用。
■ 注解
[1]
只提供单实例个人版（Single-instance Personal Edition，PSE）供下载。
[2]
报价可以从销售代表处获得。
[3]
部分支持服务只提供给有效维护合同的拥有者访问。
[4]
社团规模只相对其他OODB产品而言。OODB的用户社团远远小于关系数据库的用户社团。
[5]
持久类必须进行事后处理。
[6]
多个数据库之间的负载平衡看来不太可能。相反，处理通过客户端缓冲得以分布，它把更多的逻辑和计算任务透明地移到了客户端，从而减小了服务器的负载。
[7]
这些数据未经证实，主要从供应商的声明获得。在讨论数据库大小的时候，对象的复杂性、大小、“合理的应答时间”等问题都是必须考虑的因素。
[8]
多版本并发控制（Multiversion Concurrency Control，MVCC）是一种非标准的技术，在并发读取/写入操作期间用来维持缓冲客户端和服务器端数据视图的一致性。
[9]
可以从大量在线演示、FAQ、论坛获益，所有这一切都对现有和潜在用户开放。
[10]
实现了一种私有的VQL语言，它和OQL有一些共同点。
[11]
通过复制实现部分负载平衡能力；根据推测，负载平衡可能通过把请求重定向到多个数据库实现，但这一点未经证实。多个数据库之间的透明复制确保了每一个OODB上都有一份最新的数据。
[12]
需要64位的版本，以便超越大量在内村、记录计数等方面的2^32限制；Versant的64位版本已经构造完毕，但还没有在所有它所支持的平台上经过验证。
[13]
提供一些用于查询调整和计时的工具。
[14]
如果不是我在什么地方错过，它似乎没有提到粒度更小的安全机制或者是在API中提供这方面的能力。我找到特别提及的只是通过OS强制的数据库文件权限实现的数据库级访问控制。
[15]
需要单独提供的工具。
[16]
Poet分三种形式：t2（实时嵌入式Java），e7（嵌入式Java/C++），以及t7（企业Java/C++）。版本号没有明确显示，t7的v8.0得自文件的版本号，当前是8.0.0.19。
[17]
不能保证它完整地支持ODMG 3.0 OQL，但覆盖范围看来相当广泛。
[18]
包含一个C++或Java的嵌入式版本，以及一个Java的实时嵌入式版本。
[19]
联机支持网站community.fastobjects.com的内容非常全面，但速度常常很慢。我拥有高速连接，但它有规律地返回页面超时错误。
[20]
我只能通过命令行接口使用批量导入/导出功能。
[21]
没有分布式功能的任何明显标记，而且我也没有用过一个分布式的配置。如果Poet的配置中数据库复制带有“reader scalability”选项，负载平衡可以在某种程度上得以实现，使得查询可以对只读的从属数据库进行。
[22]
至少JDK 1.2看来最好，你将得到更好的集合支持和避免一些已经有报道的“quirk”问题（未能肯定是否为JDK 1.1解决了这些问题）。
[23]
很难进行评估。我从收入和Internet/新闻组的讨论入手分析。请把它看成是一种猜测。
[24]
持久类的标识或者是它从ooObj派生，或者它实现IooObj接口。
[25]
虽然对整个容器加锁听起来吓人，但它的基本思想是，它会显著减少加锁服务器的负载。
[26]
通过API调用和统计功能提供一些运行时查询调试能力。
[27]
一些资料，例如这一份说明，显示出这些选项会增加成本。
[28]
没有提供类似OQL的等价语言。SQL++是一种遵从SQL的功能，允许针对OODB进行SQL查询；容器支持一个scan()方法，以及支持“谓词查询语言”表达式（Predicate Query Language）。
[29]
这四种产品都提供评估版供下载。下载软件包附带的文档和示例一般都比较完善。
