1

我正在处理使用 MongoDB 的类似 CMS 的系统。每个项目都应进行版本控制，并且还应该有一个草稿版本。大多数时候，我们只对当前发布的版本感兴趣。

所以，我一直在思考以下问题：

{
   _id: "42",
   current: {
     name: "item1",
     detail: "baz"
   },
   draft: {
     name: "item1",
     detail: "draft stuff"
   },
   versions: [
                {
                  version: "1",
                  name: "item1"
                  detail: "foo"
                },
                {
                  version: "2",
                  name: "item1"
                  detail: "bar"
                }
              ]
 }

新电流的创建将首先通过“草稿”，在发布阶段它将取代当前，旧电流将移至版本阵列。类似地，通过制作副本草稿可以回滚到旧版本。

这在 MongoDB 的上下文中有意义吗？我应该将版本作为数组保存在与当前项目相同的文档中吗？

4

2 回答 2

2

真的，我认为如果您需要像文档的关键功能这样的版本 - 您可能需要看看 CouchDB - 他们有开箱即用的文档版本，并且使用它们非常容易操作，只需付出超小的开发努力（很多少于你需要的 MonogoDB)

具体谈谈您的案例，我认为您的解决方案很好，除非您的文档版本数量非常庞大（因为文档有限）。

于 2013-11-04T14:06:47.083 回答
1

在 MongoDB 中设计文档结构时，最简单的方法是考虑访问模式和数据局部性。

每次加载文档时都需要所有版本吗？将版本分开在单独的集合中是否更有意义？您还需要考虑更新/插入文档。如果您有两个单独的集合，则很难保证它们之间的一致性（与一个文档/集合中的所有内容相比）。

此外，您没有指定数据的大小以及版本更改的频率。如果文档很大（大量数据和版本），您需要考虑每个文档 16MB 的限制。

要回答您的问题 - 您提出的结构是有道理的，但您需要考虑它如何适合您的应用程序。

于 2013-11-04T14:06:55.880 回答