面向 Java 开发人员的 db4o 指南.docVIP

面向 Java 开发人员的 db4o 指南 面向 Java 开发人员的 db4o 指南 信息存储和检索作为同义语伴随 RDBMS 已经 10 来年了，但现在情况有所改变。Java 开发人员尤其厌倦于所谓的对象关系型阻抗失配，也对试图解决这个问题失去了耐心。再加上可行的替代方案的出现，就导致了人们对对象持久性和检索的兴趣的复苏。本系列是对开放源码数据库 db4o 的详尽介绍，db4o 可以充分利用当前的面向对象的语言、系统和理念。要下载 db4o，可以参考 db4o 主页；为了实践本系列的示例，需要下载 db4o。 面向 Java 开发人员的 db4o 指南: 简介和概览 2007 年 4 月 09 日 早就听说数据库间的大战以关系型数据库的胜利告终。然而，这之后，编程界真的就风平浪静、一片繁荣了吗？持肯定观点的人恐怕最近都没有试过使用关系数据库来支持 Java? 对象吧。著名作家和讲师 Ted Neward 为我们带来了这个由多个部分组成的 系列 ，深入介绍了 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）来解决这个问题。