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 を確認する必要があると思います。CouchDB には、すぐに使用できるドキュメント バージョンがあり、非常に小規模な開発作業で操作が非常に簡単です (多くの場合、 MonogoDB に必要な量より少ない)

具体的にあなたのケースについて話すと、ドキュメントのバージョンの量が非常に大きくならない限り（ドキュメントが限られているため）、ソリューションは問題ないと思います。

于 2013-11-04T14:06:47.083 に答える
1

MongoDB でドキュメントの構造を設計する場合、最も簡単な方法は、アクセス パターンとデータの局所性を考慮することです。

ドキュメントをロードするたびにすべてのバージョンが必要ですか? バージョンを別のコレクションに分ける方が理にかなっていますか? また、ドキュメントの更新/挿入についても考える必要があります。2 つの別個のコレクションがある場合、それらの間の一貫性を保証することは難しくなります (1 つのドキュメント/コレクション内のすべてに対して)。

また、データのサイズと、バージョンが変更される頻度も指定していません。ドキュメントが巨大になる場合 (大量のデータとバージョン)、ドキュメントあたり 16MB の制限について考える必要があります。

あなたの質問に答えるために - あなたが提案した構造は理にかなっていますが、あなたのアプリにどのように適合するかを考える必要があります.

于 2013-11-04T14:06:55.880 に答える