CouchDB版本控制策略

Question

以下是实现版本控制的可行策略(使用“示例”作为示例文档类型)：

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

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

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

找到特定的版本包括检索example_original文档并应用所需的更改(主要是某个特定的时间戳，但也可以是许多更改)。

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

你认为这种方法有什么优点和缺点？

Answer 1

我首先担心的是:当“获取”某个版本时，您是否可以在不修改数据库的情况下将更改应用于原始版本？

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

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

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

每个文档都有一个“历史文档”，可以更快地导航历史，但父指针更“安全”(因为您不能轻易地用它们创建非法结构)。

1. 创建新版本时，请重用UUID并指定新的唯一版本。更新历史记录文档或父指针。

这种策略非常容易实现，并允许稍后的各种灵活性。您可以轻松地擦除部分历史记录，重命名非常简单，并且您可以创建分支。

Answer 2

Simple Document Versioning with CouchDB

本文中描述的versioning as attachments方法应该可以满足大多数人的版本控制需求。

Answer 3

这些文件的业务状态是什么，特别是法律？我曾经在这样的情况下工作过，从业务角度来看，您的提案并不合适，因为需要证明作为v.3呈现的文档确实是文档的版本3。动态应用增量不会减少遵从性的影响。

正如您所说，如果文档的更改很少，那么通过存储增量而不是整个文档将不会节省很多磁盘空间。存储整个文档还允许可靠地预测任何文档的检索时间。它还降低了检索过程的复杂性。