私は今しばらく答えようとしてきましたが、理解できない質問があります：
CouchDBのドキュメントをどのように設計または分割しますか？
たとえば、ブログ投稿を見てください。
これを行う「リレーショナル」な方法は、いくつかのオブジェクトを作成することです。
- 役職
- ユーザー
- コメント
- 鬼ごっこ
- スニペット
これは非常に理にかなっています。しかし、私は同じことをモデル化するためにcouchdbを使用することを試みています（それがすべての理由で素晴らしい）ため、それは非常に困難でした。
そこにあるブログの投稿のほとんどは、これを行う方法の簡単な例を示しています。基本的には同じ方法で分割しますが、各ドキュメントに「任意」のプロパティを追加できると言っていて、これは間違いなく便利です。したがって、CouchDBには次のようなものがあります。
- 投稿（ドキュメント内のタグとスニペット「疑似」モデルを使用）
- コメント
- ユーザー
コメントとユーザーをそこに投入できると言う人もいるでしょうから、次のようにします。
post {
id: 123412804910820
title: "My Post"
body: "Lots of Content"
html: "<p>Lots of Content</p>"
author: {
name: "Lance"
age: "23"
}
tags: ["sample", "post"]
comments {
comment {
id: 93930414809
body: "Interesting Post"
}
comment {
id: 19018301989
body: "I agree"
}
}
}
それはとても見栄えがよく、理解しやすいです。また、すべての投稿ドキュメントからコメントのみを抽出したビューを作成して、それらをユーザーやタグと同じようにコメントモデルに取り込む方法も理解しています。
しかし、「サイト全体を1つのドキュメントにまとめないのはなぜですか」と思います。
site {
domain: "www.blog.com"
owner: "me"
pages {
page {
title: "Blog"
posts {
post {
id: 123412804910820
title: "My Post"
body: "Lots of Content"
html: "<p>Lots of Content</p>"
author: {
name: "Lance"
age: "23"
}
tags: ["sample", "post"]
comments {
comment {
id: 93930414809
body: "Interesting Post"
}
comment {
id: 19018301989
body: "I agree"
}
}
}
post {
id: 18091890192984
title: "Second Post"
...
}
}
}
}
}
簡単にビューを作成して、必要なものを見つけることができます。
次に、私が持っている質問は、ドキュメントを小さいドキュメントに分割するタイミング、またはドキュメント間の「関係」を作成するタイミングをどのように決定するかです。
次のように分割すると、「オブジェクト指向」のほうがはるかに多くなり、値オブジェクトにマッピングしやすくなります。
posts {
post {
id: 123412804910820
title: "My Post"
body: "Lots of Content"
html: "<p>Lots of Content</p>"
author_id: "Lance1231"
tags: ["sample", "post"]
}
}
authors {
author {
id: "Lance1231"
name: "Lance"
age: "23"
}
}
comments {
comment {
id: "comment1"
body: "Interesting Post"
post_id: 123412804910820
}
comment {
id: "comment2"
body: "I agree"
post_id: 123412804910820
}
}
...しかし、その後はリレーショナルデータベースのように見え始めます。また、「ドキュメント内のサイト全体」のようなものを継承することがよくあるため、リレーションでモデル化するのはより困難です。
私は、リレーショナルデータベースとドキュメントデータベースをどのように/いつ使用するかについて多くのことを読んだので、ここでは主な問題ではありません。CouchDBでデータをモデル化する際に適用すべき良いルール/原則は何でしょうか。
別の例は、XMLファイル/データです。一部のXMLデータには10レベル以上のネストがあり、ActiveRecord、CouchRest、またはその他のオブジェクトリレーショナルマッパーからJSONをレンダリングするのと同じクライアント（たとえば、Ajax on Rails、またはFlex）を使用してそれを視覚化したいと思います。以下のようなサイト構造全体である巨大なXMLファイルを取得することがあり、Railsアプリで使用するためにそれを値オブジェクトにマップする必要があるため、データをシリアル化/非シリアル化する別の方法を記述する必要がありません：
<pages>
<page>
<subPages>
<subPage>
<images>
<image>
<url/>
</image>
</images>
</subPage>
</subPages>
</page>
</pages>
したがって、CouchDBに関する一般的な質問は次のとおりです。
- 文書を分割するためにどのようなルール/原則を使用していますか（関係など）？
- サイト全体を1つのドキュメントにまとめても問題ありませんか？
- もしそうなら、（上記の大きなjsonの例やxmlの例のように）任意の深度レベルを持つドキュメントのシリアライズ/デシリアライズをどのように処理しますか？
- または、それらをVOに変換せずに、「これらはオブジェクトリレーショナルマップにネストされすぎているため、生のXML / JSONメソッドを使用してアクセスするだけ」と決めましたか？
どうもありがとうございました。CouchDBを使用してデータを分割する方法の問題は、「これが私がこれからどうやってやるべきか」と言うのが困難でした。早く着くといいな。
以下のサイト/プロジェクトを調査しました。
- CouchDBの階層データ
- CouchDB Wiki
- ソファ-CouchDBアプリ
- CouchDB決定版ガイド
- PeepCode CouchDBスクリーンキャスト
- カウチレスト
- CouchDB README
...しかし、彼らはまだこの質問に答えていません。