しばらく答えようとしているのですが、わからない質問があります。
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"
}
}
}
とても見栄えが良く、わかりやすいです。また、ユーザーとタグと同じように、すべての Post ドキュメントからコメントのみを抽出してコメント モデルに取得するビューを作成する方法も理解しています。
しかし、「サイト全体を 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でデータをモデル化するときに適用するのに適したルール/原則は何ですか。
もう 1 つの例は、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 に変換しないで、「これらは Object-Relational Map にネストされすぎているので、未加工の XML/JSON メソッドを使用してアクセスするだけです」と判断しますか?
お世話になりました、CouchDBでデータをどう分割するかという問題は、「これからはこうすればいい」と言い切るのが難しかったです。私はすぐにそこに着くことを願っています。
以下のサイト/プロジェクトを調査しました。
- CouchDB の階層データ
- CouchDB ウィキ
- ソファ - CouchDB アプリ
- CouchDB 決定版ガイド
- PeepCode CouchDB スクリーンキャスト
- カウチレスト
- CouchDB README
...しかし、彼らはまだこの質問に答えていません。