CouchDB的版本管理策略

Question

请问以下是用于实现版本控制的可行策略（使用“榜样”为样本文档类型）：

具有其中类型字段example_original一个名为原始文档。

对文档的后续更改都将类型example_change和example_original文档的id作为关键字。更改也会带有时间戳。

保留一个类型为example_current的doc，它是example_original的结果，其中所有example_change均为“applied”。新的example_change文档将自动应用于此文档。

找到一个特定的版本将包括检索example_original文档并应用所需的更改（通常达到某个时间戳，但也可能是一些更改）。

我应该提到我的用例会涉及对原始数量进行的有限数量的更改。大多数更新将包含新的原始文档。虽然这是我目前的用例，但如果涉及许多更改，我也会对这些问题感兴趣。

你在这种方法中看到什么优点和缺点？

Answer 1

我的第一个担心是：当“获取”某个版本时，是否可以在不修改数据库的情况下将更改应用到原始文件？

您是否需要从历史记录中删除某些内容？你确定吗？真的，真的吗？如何分支机构？

总而言之，这看起来像一个复杂的战略。请记住，我听说过CouchDB，但从未使用它。我想去更简单的方法：

1. 当您创建一个文档时，您分配一个UUID。不要使用该名称，否则在重命名操作过程中会遇到麻烦。添加一个读取“1”的版本字段。创建第二个文档，其中包含具有相同UUID的文档列表，或向第一个文档添加“父”指针。

   为每个文档创建一个“历史文档”可以更快地导航历史记录，但父指针更“安全”（因为您无法轻松地使用它们创建非法结构）。

2. 当您创建新修订版时，请重新使用UUID并指定一个新的唯一版本。更新历史文档或父指针。

这个策略实现起来相当简单，并允许以后各种灵活性。您可以轻松擦除历史的一部分，重命名很简单，并且您可以创建分支。

Answer 2

这些文件的商业状态是什么，尤其是合法的？由于需要证明作为v.3提供的文档确实是文档的第3版，所以我曾经在您的建议不适合业务持续性的情况下工作。动态应用三角洲不会削减顺应性芥末。

如果您像文中所说的那样对文件进行频繁更改，那么您将不会通过存储增量而是整个文档来节省大量磁盘空间。存储整个文档还可以可靠地预测任何文档的检索时间。它还降低了检索过程的复杂性。

Answer 3

使用CouchDB进行版本控制的策略是不要压缩包含需要保留完整历史记录的文档的数据库。您仍然可以压缩其他数据库。采用编辑冲突解决策略，这种简单的策略即刻起作用。

删除文档可以通过编写没有内容但删除属性集的新版本来完成。

分支无法这样做，因为版本控制机制提供了单个修订版本的线程。

现在对于CouchDB的可能的未来：

• 今天，每个版本保存文档的完整副本，但人们可以认为，CouchDB的引擎优化有朝一日商店增量。
• 未来，CouchDB可能会提供一个API来防止压缩某些文档类型。这将允许将所有文档保存在同一个数据库中。这对于CouchDB来说是一个简单的补丁。
• 该策略确实可以对文档分支进行管理，但考虑到CouchDB作为文档数据库的性质，这是一种合理而长期的可能性。

Answer 4

Simple Document Versioning with CouchDB

作为附件这篇文章应该适合版本大多数人的要求，在方法上描述的版本。