这是其中之一“我知道我不应该这样做，但它非常方便。”的问题。对不起。
我计划使用CouchDB存储一堆文档并保留其整个修订历史记录。 CouchDB自动进行版本控制，但它是strongly discouraged for programmer's use：
“除了并发控制之外，您不能将文档修订用于任何其他目的。”
根据我在CouchDB wiki上发现的内容，版本可能会在compaction期间或replication期间被删除。据我所知，压缩必须始终手动触发，只有在有多个数据库服务器时才会发生复制。
问题是：如果我不运行压缩并且只对我的文档使用单个数据库实例，我可以使用CouchDB的文档版本并期望它能够工作吗？
我可能会遇到哪些其他问题？例如。没有运行压缩会损害性能或消耗更多的磁盘空间（比我手动处理版本控制的那样）？
答案 0 :(得分：8)
如果你重新改写句子，它会说：“任何更新，无论未成年人如何都可以彻底改变行为。我们保证你可以将它用于并发，但没有别的。”
因此，我不会依赖它，因为在我们的行业中，像这样的东西会在6个月内困扰你，除非你绝对可以保证永远不会更新CouchDB。
答案 1 :(得分：4)
如果错了，那我就不想做对了！
实际上，没有。这是不对的。迈克尔解释得很好：最好的情况是它使你的应用程序不能面向未来，而最坏的情况是你会得到不好的错误，迫使你在不方便的时候重新设计。
考虑使用Google App Engine。他们建议的交易模式是什么？
这些形成了一个在事务失败时重新运行的函数。为什么？为什么必须在事务中获取而不是在外部范围内闲逛？
因为App Engine在内部使用MVCC。如果你发生碰撞（你的修改版本错误，因为其他人更新了），那么他们只是重新运行你的功能。下一次迭代将获取较新的版本，从较新的数据更新，并使用正确的版本重新放置。关键是，谷歌不会向用户公开这个，因为它不适合构建应用程序级版本。