关系数据库并不是企业中的 Python 程序员唯一可用的解决方案。通常，对象数据库可能更适合解决某些问题。本文将讨论 ZODB，ZODB 是一个可扩展和冗余的对象数据库，其专注于存储可扩展的对象，而没有天生的“对象-关系”不匹配情况；在尝试将面向对象的语言与关系查询系统映射对象建立关系时，可能会出现这种不匹配情况。
正如采用静态类型化的语言进行编程的朋友们一样，Python 和其他动态语言的程序员通常使用关系数据库作为后端数据存储区。无论他们是使用 SQL 来直接定义数据库表，还是使用他们的框架或 ORM 作为备选方案提供的模式语言，所有此类解决方案都提供了相似的工作流：应用程序设计人员必须指定每个类的实例将支持的每个属性的名称、类型和约束，相应地，实例化的数据库关系要能够持久化那些对象的实例。
十多年以前，Zope Corporation 最先提供了一种备选方案，该备选方案旨在更好地适应动态语言的数据模型：Zope 对象数据库（Zope Object Database，ZODB），该数据库专注于存储可扩展的对象而不是传统的关系。今天，ZODB 已成为由 Zope 提供支持的 Web 应用程序的最常用数据库引擎。
应该使用 ZODB 还是使用关系数据库之上的 ORM，这个决定涉及到重要的权衡，本文将对此问题进行探索，并提供了 ZODB 实例的基本维护指南。
ZODB 包括一个 BTree 实现，允许定义和使用关系样式的结构。Zope“目录”的用法非常类似于关系表。用于根对象的对象不是非常可伸缩。大型集合应该使用放在根对象（当然包括根对象之下）中的 Btree。此外，根对象的键并不仅限于字符串。
 |
|
ZODB 与关系数据库的关系就如同 Python 与诸如 Java™ 等静态类型化语言的关系。对于许多应用程序，尤其是涉及到复杂对象的应用程序，诸如 ZODB 等数据库要容易处理得多。这是 ZODB 成为 Zope 应用程序的最常用后端的关键原因。
对象数据库和关系数据库之间的另一个重要区别在于，对象数据库存储已经组装好的对象。在关系数据库中，无法表示为基本数据值的记录的对象必须通过数据库联结进行组装。无论是在概念上还是在计算上，这可能代价非常高并且非常麻烦。
ZODB 对其提供的服务采用了一种最低要求的方法。它提供基本的持久性，但也仅此而已。诸如安全性和索引等其他服务必须在应用程序级别提供。此方法具有优点和缺点。它允许 ZODB 开发人员集中于核心服务，并使得创新更加容易，但是也让有些人感觉意犹未尽。缺乏数据库级别的安全模型使得充分利用 ZEO 存储服务器变得非常困难，因为客户端或多或少地拥有对数据库的自由访问，因此客户端必须受信任。
为 ZODB 构建索引功能是相当简单，但是除了 Python 以外，不存在任何其他查询语言。例如，要从人员集合中选择名为 Smith 的人员，我们可以使用 Python 列表理解 (list comprehension)：
本文转自IBM Developerworks中国