CouchDBとドキュメントのバージョン管理

現在、CouchDBを使用してwiki風のアプリケーションに取り組んでおり、ドキュメントのバージョン管理スキームを実装しようとしています。私がそれを見る方法には、これを行う2つの方法があります：

1. 各バージョンを個別のドキュメントとして保存する
2. 古いバージョンを添付ファイルとして単一のドキュメントに保存します。

今、私は＃1が働いている形を持っています。ユーザーがドキュメントを編集して保存すると、バックエンドはまず前のリビジョンを新しいドキュメントにコピーしてから、新しいバージョンを保存します。各ドキュメントには、各バージョンのデータ（古いバージョンのドキュメント_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（改訂）の別のドキュメントであり、ディスク上のスペースを消費することに注意してください。

確かに、非常に大きなディスクが必要であることを意味するすべてのリビジョンを保持する必要があります。