ZODB在现实生活中
使用Python编写应用程序，并使用各种ORM设置和直接的SQL进行操作。 所有这些都是丑陋的罪过。
我一直在寻找ZODB作为一个对象存储，它看起来很有希望的替代scheme…你会推荐它吗？ 什么是您的经验，问题和批评，特别是关于开发人员的观点，可扩展性，完整性，长期维护和替代？ 任何人开始一个项目，并把它呢？ 为什么？
虽然ZODB，Pypersyst和其他人的想法很有趣，但似乎对他们缺乏热情:(
我已经使用ZODB超过十年了，在Zope和外面。 如果你的数据是分层的，那就太好了。 一个客户经营的最大的数据存储可能..我不知道… 100GB的呢？ 无论如何，这个数量级的东西。
这是一个与Postgres的性能比较 。
如果您正在编写一个WSGI Web应用程序，这些包可能是有用的：
-
repoze.tm2 （ docs ）
-
repoze.zodbconn （ docs ）
与“任何键值存储”相比，ZODB的关键特性是将属性更改与实际的ACID事务自动集成，并清除对其他持久对象的“任意”引用。
ZODB不仅仅是Zope中默认使用的FileStorage：
- RelStorage后端使您可以将数据放入RDBMS中，使用标准工具进行备份，复制等。
- ZEO允许轻松扩展应用程序和脱机作业。
- 两阶段提交支持允许协调多个数据库之间的事务，包括RDBMS（假设它们提供了TPC感知层）。
- 简单的基于对象属性或遏制的层次结构：您不需要编写recursion自连接来模拟它。
- 基于文件系统的BLOB支持使服务大文件变得微不足道。
总的来说，我很高兴使用ZODB几乎所有的数据形状都不是明显的“方形”的问题。
我会推荐它。
我真的没有任何批评。 如果它是您寻找的对象商店，这是使用的。 我之前已经存储了250万个对象，并没有感觉到掐指。
ZODB已被用于大量的大型数据库
大多数ZODB的用法是/可能是Zope用户，如果他们从Zope迁移出去，他们就会迁移出去
性能不如relatonal database + ORM，尤其是如果你有很多的写操作。
长期维护并不是那么糟糕，你想不时打包数据库，但可以现场完成。
如果要使用ZODB的多个进程，则必须使用ZEO，这比直接使用ZODB要慢很多
我不知道ZODB如何在闪存盘上执行。
通过酸洗，您应该能够以类似的方式使用任何键值数据库。
