标签：
业界对持久存储领域的追求从未停止过，为了更方便、更容易地用对象表达我们的思维，开源领域和商业领域都涌现了许多新技术， ORM 的出现恰恰说明了这点。最近一年，业界也在反思，到底 ORM 给我们带来的是便利还是麻烦。矛头指向大名鼎鼎的 Hibernate ，纷纷议论其性能问题，大家似乎要达成这样的共识：“在业务逻辑复杂的地方用 SP ，而一般的 CRUD 还是 Hibernate ”，就连全球知名的 BearingPoint 也有类似看法。下面一个简单的例子，说明了传统 ORM 工具的弊端。让我们考虑一个简单的 Student 对象如 清单1：
清单1. Student 类
public class Student {
private String name;
private int age;
public String getName(){
return name;
}
public int getAge(){
return age;
}
}
考虑下面这个场景:找到“年龄小于 20 岁的所有学生”？
使用 ORL 实现如 清单2：
清单2. ORL 实现
String oql = "select * from student in AllStudents where student.age <20"; OQLQuery query = new OQLQuery(oql); Object students = query.execute();
使用 JDOQL 实现如 清单3：
清单3. JDOQL 实现
Query query = persistenceManager.newQuery(Student.class, "age <20"); Collection students = (Collection)query.execute();
上面的方法都存在一些普遍问题：
现代集成开发环境不会检查内嵌字符串的语义和语法错误。在上面所有查询语句中， age 字段和数值 20 都被认为是数字类型，但是没有一个 IDE 或编译器能检查其实际正确性。如果开发者混淆了查询代码－―比如，改变了 age 字段的名字或类型，将导致――上面所有的查询语句在运行时报错，而不会在编译时提示。
现代敏捷开发技术鼓励不断进行重构来维持清晰和与时俱进的类模型，以便准确重现不断演进的域模型。如果查询代码难于维护，它会延迟决定重构的时间并不可避免的引入低质量代码。
所有列出的查询都直接用 Student 类的私有成员 age，而不是使用它的公共接口 student.getAge()，因此他们都破坏了面向对象封装规则，违反接口和实现应该分离的面向对象法则。
所有的查询都非 100% 的原生。
既然存在如此多的问题, 为什么不直接使用纯面向对象数据库呢？有些开发者可能会说：“它缺乏数学模型的支持， 还不够成熟”。的确， RDBMS 发展了几十年才有今天的成就，已经非常完善了。而技术的革新是无止境的, 故步自封的永远都跟不上变化的脚步。
让我们来简单回顾一下对象数据库的发展史（资料来源于 Wiki 百科全书）：“面向对象数据库系统”这一术语第一次出现于 1985 年。著名的研究项目包括：Encore-Ob/Server ( 布朗大学）， EXODUS（Wisconsin 大学）， IRIS （惠普）， ODE （ Bell 实验室）， ORION （MCC ） ，Vodak （GMD-IPSI）和 Zeitgeist （Texas Instruments）。其中以 ORION 项目发表的论文数为最多。 MCC 的 Won Kim 将这些论文中最有价值的一部分汇编成书并由 MIT 出版社出版。对象数据库管理系统为面向对象编程语言增加了持久的概念。最早的商品化 ODBMS 出现在 1986 年，是 Servio 公司（现在的 GemStone 公司）和 Ontos 公司推出的。后来（九十年代） Object Design （ ODI ）、 Versant 、 Objectivity 、 O2 Technology 、 Poet 、 Ibex 、 UniSQL 和 ADB MATISSE 等公司也加入了这个开拓行列。
而今天，一家来自加州硅谷的开源面向对象数据库公司 db4objects 为我们带来了db4o， 一款性能卓越的纯面向对象数据库，也是我们这篇和后续文章将会介绍的主角。
db4o 为我们带来的是这样一种面向对象的查询方式：
100% 的原生 查询语言应能用实现语言（ Java 或 C# ）完全表达，并完全遵循实现语言的语义。
100% 的面向对象 查询语言应可运行在自己的实现语言中，允许未经优化执行普通集合而不用自定义预处理。
100% 的类型安全 查询语言应能完全获取现代 IDE 的特性，比如语法检测、类型检测、重构，等等。
“利用表格存储对象，就像是将汽车开回家，然后拆成零件放进车库里，早晨可以再把汽车装配起来。但是人们不禁要问，这是不是泊车的最有效的方法呢。” – Esther Dyson
db4o 是一个开源的纯面向对象数据库引擎，对于 Java 与 .NET 开发者来说都是一个简单易用的对象持久化工具，使用简单。同时，db4o 已经被第三方验证为具有优秀性能的面向对象数据库， 下面的基准测试图对 db4o 和一些传统的持久方案进行了比较。db4o 在这次比较中排名第二，仅仅落后于JDBC。通过图 1 的基准测试结果，值得我们细细品味的是采用 Hibernate/HSQLDB 的方案和 JDBC/HSQLDB 的方案在性能方面有着显著差距，这也证实了业界对 Hibernate 的担忧。而 db4o 的优异性能，让我们相信： 更 OO 并不一定会牺牲性能。
图1. HSQLDB 基准测试
同时，db4o 的一个特点就是无需 DBA 的管理，占用资源很小，这很适合嵌入式应用以及 Cache 应用， 所以自从 db4o 发布以来，迅速吸引了大批用户将 db4o 用于各种各样的嵌入式系统，包括流动软件、医疗设备和实时控制系统。
db4o 由来自加州硅谷的开源数据库公司 db4objects 开发并负责商业运营和支持。db4o 是基于 GPL 协议。db4objects 于 2004 年在 CEO Christof Wittig 的领导下组成，资金背景包括 Mark Leslie 、 Veritas 软件公司 CEO 、 Vinod Khosla （ Sun 公司创始人之一）、 Sun 公司 CEO 在内的硅谷高层投资人组成。毫无疑问，今天 db4objects 公司是硅谷炙手可热的技术创新者之一。
db4o 的目标是提供一个功能强大的，适合嵌入的数据库引擎，可以工作在设备，移动产品，桌面以及服务器等各种平台。主要特性如下：
开源模式。与其他 ODBMS 不同，db4o 为开源软件，通过开源社区的力量驱动开发 db4o 产品。
原生数据库。db4o 是 100% 原生的面向对象数据库，直接使用编程语言来操作数据库。程序员无需进行 OR 映射来存储对象，大大节省了程序员在存储数据的开发时间。
高性能。图2为 db4o 官方公布的基准测试数据，db4o 比采用 Hibernate/MySQL 方案在某些测试线路上速度高出 44 倍之多！并且安装简单，仅仅需要 400Kb 左右的 .jar 或 .dll 库文件。在接下来的系列文章中，我们将只关注在 Java 平台的应用，但是实际上 db4o 毫无疑问会很好地在 .NET 平台工作。
图2. db4o 官方基准测试数据
易嵌入。使用 db4o 仅需引入 400 多 k 的 jar 文件或是 dll 文件，内存消耗极小。
零管理。使用 db4o 无需 DBA，实现零管理。
支持多种平台。db4o 支持从 Java 1.1 到 Java 5.0，此外还支持 .NET 、 CompactFramework 、 Mono 等 .NET 平台，也可以运行在 CDC 、 PersonalProfile 、 Symbian 、 Savaje 以及 Zaurus 这种支持反射的 J2ME 方言环境中，还可以运行在 CLDC 、 MIDP 、 RIM/Blackberry 、 Palm OS 这种不支持反射的 J2ME 环境中。
或许开发者会问，如果现有的应用环境已经有了关系型数据库怎么办？没关系，db4o 的 dRS（db4o Replication System）可实现 db4o 与关系型数据库的双向同步（复制），如图 3 。 dRS 是基于 Hibernate 开发，目前的版本是 1.0 ，并运行在 Java 1.2 或更高版本平台上，基于 dRS 可实现 db4o 到 Hibernate/RDBMS 、 db4o 到 db4o 以及 Hibernate/RDBMS 到 Hibernate/RDBMS 的双向复制。dRS 模型如 图3。
图3. dRS 模型
db4o 因为其开源的理念，以及创新的实现，获得了 Java Pro 2006 读者选择奖。无论从成功案例还是 db4o 本身来看，这款纯面向对象数据库都值得我们关注，从官方论坛反馈情况看，有相当的用户准备把关系型数据库迁移到 db4o 。而最新发布的 5.5 版本，更是把性能再次提升很多。在接下来的文章中，我会继续和大家分享 db4o 给我们带来的这场面向对象数据库风暴。
学习
db4o 官方网站 。
面向对象数据库 db4o 之旅系列：查看此系列文章完整列表。
ODMG 官方网站：了解 ODMG 技术。
developerWorks Java 技术专区：数百篇关于 Java 编程各个方面的文章。
获得产品和技术
标签：
原文地址：http://my.oschina.net/xionghui/blog/489703
