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

核心提示： 运行上述代码，会看到检索出两个对象，面向 Java 开发人员的 db4o 指南: 简介和概览(6)，但是...在您将我定义为狂热的推崇者之前，请允许我先列举几条反对 db4o 的言论，持久性方法仅仅是一个实现细节，因此，db4o 几乎无法对应于现有的 Oracle、SQLServer 或 DB2

运行上述代码，会看到检索出两个对象。

但是...

在您将我定义为狂热的推崇者之前，请允许我先列举几条反对 db4o 的言论。

db4o 几乎无法对应于现有的 Oracle、SQLServer 或 DB2！完全正确。相比之下，db4o 更适合于 MySQL 或 HSQL，这使其对于大量项目来说已经足够。更为重要的是，开销一直是 db4o 开发人员特别关注的事情，这又让它特别适于小型的嵌入式环境。（我这里给出的示例只是一个简单的演示，和其他任何小型的演示一样，请务必清楚一点，即姑且不论它相比其他工具具有多少潜力，db4o 都会比您在这里所看到的要强大许多。）

我不能用 JDBC 在 db4o 上进行查询！确实如此，尽管 db4o 团队曾想过创建 JDBC 驱动程序以让对象数据库能接受 SQL 语法，即一种所谓的 “关系对象映射”。（开发团队之所以没有这么做，据说是因为没有这个必要，而且性能会因此大受影响。）问题的关键是，您在实现中使用的是对象（POJO），除此之外别无他物。若不存储关系，为何还要使用 SQL 呢？

但是我的其他程序如何获得数据呢？这要看具体情况。如果您这里所谓的 “其他程序” 指的是其他 Java 代码，那么只需在这些程序内使用 Person 类的定义并将其传递进 ObjectContainer，正如我这里所做的一样。在 OODBMS 内，类定义本身就充当模式，所以无需其他的工具来获取 Person 对象。但是如果您这里所谓的 “其他程序” 指的是其他语言的代码，那么问题就会复杂一些。

对于 db4o 不支持的语言，比如 C++ 或 Python，数据基本上是访问不到的，除非是您能从 Java 代码构建程序。db4o 适用于 C# 和其他的 .NET 语言，而其数据格式在二者之间是兼容的，这就使得 Java 对象对同样定义的 .NET 类也可用。如果您这里所谓的 “其他程序” 指的是使用 SQL 和标准调用级接口（比如 ODBC 或 JDBC）来与数据库进行交互的报告工具，那么 db4o（或与此相关的任何 OODBMS）可能未必是很好的选择。机警的读者会发现报告功能现在对 OODBMS 还不可用，但好消息是：已针对此问题发起很多产品和项目，而且 db4o 还支持 “复制（Replication）”，它允许 db4o 实例将数据从其自身的存储格式复制进 RDBMS。

但它是个文件！在这种特殊情况下，确实如此；但正如前面所讲，db4o 在何处和如何存储数据方面十分灵活，而且还提供了一个轻量级的客户机/服务器选项。如果您所期待的是功能完善的 RDBMS 所能提供的冗余性，那么 db4o 并不能如您所愿（但其他的 OODBMS 能提供这类特性）。

但当我再次运行示例时，我会得到副本！（实际上，我每次运行该示例都会得到副本。）这里，实际上回到了我们所讨论的第一个有趣的问题：身份，正是这一点将对象数据库和关系数据库区分开来。正如我前面所言，对象系统中的身份是通过隐式的 “this” 引用赋予的，Java 对象使用这个引用在内存中标识其自身。在对象数据库中，它被称为 OID（对象标识符），该 OID 在 OODBMS 中充当主键。

当创建新对象并将其 “放” 进数据库中时，新对象并不具有与其相关的 OID，因而会收到其自身惟一的 OID 值。它会复制，就如同 RDBMS 在执行每个 INSERT 操作时生成主键所做的那样（比如 顺序计数器或自动增量字段）。换言之，就主键而言，OODBMS 与 RDBMS 相当接近，但主键本身并非传统 RDBMS（或过去习惯使用 RDBMS 的程序员）认为的那种主键。

换言之，db4o 旨在解决某些方面的问题，而不是成为解决全部持久性问题的一站式通用解决方案。实际上，这让 db4o 首轮就战胜了 OODBMS：db4o 无意向那些生产 IT 人员宣称自己是多么好的一种理念，以至于完全可以放弃他们在关系数据库上的投资。

结束语

传统的集中关系型数据库作为数据存储和操纵的首选工具的地位在短期内无法撼动。以这种数据库为基础发展起来的工具非常之多，历史也很久远，而且许多程序员也都陷在 “我们总需要数据库” 的思维模式之中，这些无疑加固了其地位。实际上，db4o 在技术上的设计和定位并不是为了挑战 RDBMS 的这一地位。

但 “面向服务” 社区迫切要求我们构建松散耦合的多层世界，当您开始将 OODBMS 放到这种环境中去审视的时候，有趣的现象就出现了：如果要实现组件（服务、层或诸如此类的东西）间真正的松散耦合，那么结果常常是某种程度的耦合只存在于服务的调用程序和该服务的公开 API（或 XML 类型，不管您如何看待它）之间。无需数据类型，无需公开对象模型，无需共享数据库 —— 本质上讲，持久性方法仅仅是一个实现细节。因此，在大量场景中可用的持久性方法的范围会显著扩大。