面向 Java 开发人员的 db4o 指南: 简介和概览

你是否正在寻找关于db4o的内容？让我把最棒的东西奉献给你：

在我出道成为程序员的时候，之战似乎已完全平息。Oracle 和其他几个供应商都非常支持和看好关系模型及其标准查询语言 SQL。实际上，坦率地讲，我从未将任何关系的直接祖先，比如 IMS 或无处不在的平面文件，用于长期存储。客户机/服务器看起来似乎长久不衰。

之后，忽然有一天，我发现了 C++。正像许多在这个特别的时刻发现了这个特别的语言的其他人一样，它改变了我的整个编程 “世界观”。我的编程模型从基于函数和数据的变成了基于对象的。一时间，再也听不到开发人员大谈构建优雅的数据结构和 “信息隐藏” 了，现在，我们更热衷于多态、封装 和继承 —— 一整套新的热门字眼。

关于本系列

信息存储和检索作为同义语伴随 RDBMS 已经 10 来年了，但现在情况有所改变。Java 开发人员尤其厌倦于所谓的对象关系型阻抗失配，也对试图解决这个问题失去了耐心。再加上可行的替代方案的出现，就导致了人们对对象持久性和检索的兴趣的复苏。本系列是对开放源码 db4o 的详尽介绍，db4o 可以充分利用当前的面向对象的语言、系统和理念。要下载 db4o，可以参考 db4o 主页；为了实践本系列的示例，需要下载 db4o。

与此同时，关系已风光不再，一种新的 —— 对象 —— 成为了人们的新宠。若能再结合一种面向对象的语言，例如 C++ （或与之类似的编程新贵，Java 编程），OODBMS 真是可以堪称编程的理想王国。

但是，事情的发展并非如此。OODBMS 在 90 年代晚期达到了顶峰，随后就一直在走下坡路。原来的辉煌早已退去，剩下的只有晦涩和局限。在第二轮的之战结束之时，关系又成了赢家。（虽然大多数 RDBMS 供应商都或多或少地采用了对象，但这不影响大局。）

上述情况中存在的惟一问题是，开发人员对 OODBMS 的热衷一直没有衰退，db4o 的出现就很好地说明了这一点。

对象和关系

对象关系型阻抗失配 这个话题完全可以拿出来进行学术讨论，但简单说来，其本质是：对象系统与关系系统在如何处理实体之间的互动方面所采取的方式是截然不同的。表面上看，对象系统和关系系统彼此非常合适，但若深入研究，就会发现二者存在本质差异。

首先，对象具有身份的隐式性质（其表征是隐藏/隐式的 this 指针或引用，它实际上是内存的一个位置），而关系则具有身份的显式性质（其表征是组成关系属性的主键）。其次，关系通过隐藏范围内的数据查询和其他操作的实现进行封装，而对象则在每个对象上实现新的行为（当然，模块所实现的继承都在类定义中进行指定）。另外，可能也是最有趣的是，关系模型是个封闭的模型，其中任何操作的结果都将产生一个元组集，适合作为另一个操作的输入。这就使嵌套的 SELECT 以及很多其他功能成为可能，。而对象模型则无此能力，尤其是向调用程序返回 “部分对象” 这一点。对象是要么全有要么全无的，其结果就是：与 RDBMS 不同，OODBMS 不能从表或一组表返回任一、全部或部分列。

简言之，对象（用像 Java 代码、C++ 和 C# 这类语言实现）和关系（由像 SQLServer、Oracle 和 DB/2 这样的现代 RDBMS 实现）操作的方式有极大的差异。对于减少这种差异，程序员责无旁贷。

映射的作用

过去，开发人员曾试图减少对象和关系间的这种差距，尝试过的方式之一是手动映射，比如通过 JDBC 编写 SQL 语句并将结果收集进字段。对这种方式的一个合理的质疑是：是否还有更简化的方法来进行处理。开发人员大都用自动的对象关系映射实用工具或库（比如 Hibernate）来解决这个问题。

即使是通过 Hibernate（或 JPA、JDO、Castor JDO、Toplink 或任何可用的其他 ORM 工具），映射问题也无法彻底解决，它们只会转移到配置文件。而且，这种方式与要解决的问题颇有些风马牛不相及。比方说，如果您想要创建一个分层良好的继承模型，将它映射到表或一组表无疑是失败之举。若用对常规形式的违背来换取查询的性能，就会将 DBA 与开发人员在某种程度上对立起来。

可问题是很难构建一个富域模型（参见 Martin Fowler 和 Eric Evans 各自所著的书），不管是您以后想要调整它来匹配现有的模式，还是想要调整执行其操作的功能来支持对象模型（甚或这两者）。

但如果能不调整，岂不是更好？

进入 db4o：OODBMS 的回归

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/shenmilingyu/article-6299-1.html