CouchDB和文档版本控制

我目前正在使用CouchDB开发一个具有Wiki风格的应用程序，并且正在尝试实现文档版本控制方案。我看到它的方式有两种：

1. 将每个版本存储为单独的文档
2. 将较旧的版本存储为单个文档的附件。

现在，我有一种排名第一的工作方式。当用户编辑文档并保存时，后端首先将以前的修订版本复制到新文档中，然后保存新版本。每个文档都有一个“历史”数组，其中包含每个版本的数据（旧版本的文档_id，时间戳，编辑器等）。

由于此历史记录数组对于经常更新的文档可能会很漫长，因此我有一个视图，该视图在正常读取期间会获取没有历史记录的文档（还有另一个用于获取历史记录的视图）。

我的问题是：我对目前的方法感到不安，并一直在考虑更改为“附件”方法。但我不确定。我希望有一个比我更了解CouchDB的人（我才来这两个星期了-这是我的第一个使用CouchDB和NoSQL的项目）可以告诉我每种方法的优缺点方法。还是有其他我忽略的版本控制方案？

仅存储更改将是一个好主意，因为将较旧的文档存储为单独的文档或数据库的最终版本的附件将增加数据库服务器的开销。

每当您更改文档中的键值时，请添加一个名为的新键_h_i_s_<key_name>。在新创建的（或上一次更新期间创建的）中，在每次编辑/更新后添加如下对象：

{
key_name: "Hello",
_h_i_s_key_name:{time_of_update:value_of_key_name_before_update},
....
}

要么

    {
    key_name: "Hello",
    _h_i_s_key_name:[{time:time_of_update,value:value_of_key_name_before_update}, {time:time_of_last_update,value:value_of_key_name_before_last_update}],
    ....
    }

从长远来看，这种方法将节省大量磁盘空间和复制带宽。

没有任何有关CouchDB的知识。尽管存储每个版本可能与前一个版本的差异很小，但却浪费了存储空间。我建议仅存储更改。

您可能要在这里看看或搜索数据版本。

多年后 ;-）

您不必存储更改，因为CouchDB会为您完成更改。如果文档被更改，将创建一个新的修订版。请注意，这实际上是另一个具有相同_id但新的文档_rev（修订版），并且会占用磁盘空间。

当然，您必须保留所有意味着什么的修订，即您需要一个非常大的磁盘。