CouchDBにデータを格納して構造化する方法の良い例とプラクティスを探しています。CouchDBを構成する方法の例
最終的なガイドのブログアプリよりも少し複雑です。
Stack Overflowのようなアプリケーションを考えてみましょう。
リレーショナルデータベースでデータを構造化するのに適している概念は、ドキュメントストレージデータベースと同様に有効です。実際に変更されるのは、通常、リレーショナルデータベースの結合で通常行われるクエリは、NoSQLデータベースでは扱いにくいということです。つまり、RDBMへの結合で通常解決される1対多の関係には、通常、NoSQLデータベースの非正規化がより多く含まれます。その投稿のブログ投稿やコメントのような1対多の関係の典型的な例では、投稿に対するコメントに外部キーを使用する代わりに、投稿の一部のデータをコメントに複製して余分なまた、コメントIDのリスト（そして最新のコメント本体も10個）を投稿に残すことになります。 CouchDBの中に「ジョイン」やっに関して
：
実際にはデータを複製していない多くの意味をなすかもしれません。次に、couchdbで作成したビューの例を示します。http://wamoyo.iriscouch.com/_utils/database.html?ideageneration/_design/IdeaGeneration/_view/challengesAndIdeas
この単純なアプリケーションでは、課題を入力し、課題解決のアイデアを収集しましょう。これはブログの例にかなりよく反映されています。課題はブログの投稿となり、アイデアはブログの投稿ごとに収まるコメントになります。
私はここで別の質問への完全な詳細にこれを掲載しました：ジェイソンは、私は同じ質問で遊んだ、CouchDBの中でアプリケーションを構築に関してCouch DB Join operations like RDBMS
。 CouchDBは柔軟性が非常に高いので、データを表示するためにショーやリストを使うべきかどうか、あるいはバックボーンを使ってクライアント側のコードを書いて、モデルを供給するためにcouchdbビューを使うだけでは不十分です。あなたが何を思いついたのか教えてください。私は非常に興味があります。
このテーマで共有できる新しい発見はありますか？ – AndrewHenderson
CouchDBを使って物事を構成する方法はたくさんありますが、それは本当にあなた次第です。それはスキーマを持たないというメリット/損害です。また、あなたの答えから判断すると、あなたは私よりも優れた対処法を持っています。 – Costa
1つのデータベースにさまざまな部分（ユーザー、質問、回答、コメント、タグ、投票）を別々のドキュメントとして保存することをお勧めします。
いいえこれらを別々のデータベースに保存しないでください。ビューのパワーを失い、指数的な量のHTTPリクエストを作成してデータを収集する必要があります。
-
http://www.cmlenz.net/archives/2007/10/couchdb-joinsをチェックしてください。それは本当に私のために被写体に光を当てました。 another questionのリンクを共有すると、Costaとなります。
この記事では、ユビキタスなブログの例を使用していますが、アプローチ2は「照合照合」としています。
別のドキュメントの子であるドキュメントは、親の "_id"属性でリンクされます。また、ビューに返されたときにドキュメントを並べ替えるために、ドキュメントに「型」属性を与えます。
function(doc) {
if (doc.type == "post") {
map([doc._id, 0], doc);
} else if (doc.type == "comment") {
map([doc.post, 1], doc);
}
}
はこれです：たとえば、あなたは今、すべてのデータを持っている
{
"total_rows": 5, "offset": 0, "rows": [{
"id": "myslug",
"key": ["myslug", 0],
"value": {...}
}, {
"id": "ABCDEF",
"key": ["myslug", 1],
"value": {...}
}, {
"id": "DEFABC",
"key": ["myslug", 1],
"value": {...}
}, {
"id": "other_slug",
"key": ["other_slug", 0],
"value": {...}
}, {
"id": "CDEFAB",
"key": ["other_slug", 1],
"value": {...}
}]
}
、親と子供たちは1つのHTTPリクエストに返されます。さらに、REST APIを介してこれらのドキュメントを直接CRUDすることもできます。私の意見では、これはまさにあなたが望むものです。
1対多または多対1リレーションシップを持つものに同じアプローチを適用できます。
希望すると便利です。
http://www.cmlenz.net/archives/2007/10/couchdb-joinsで例示されているモデルは構造の理解に役立ちましたが、ブログのトピックをdoc idに使用するアプローチについて1つのコメントがあります。 2人のユーザーが同じブログタイトルを持っている場合、これは競合を引き起こします。私はcouchdbが新しくなっていますが、/ blogNameでブログを読み込むことができても、doc idとdocのタイトルを区別する必要があるようです。 {：、6377738426gdjjsb _rev：_id 1-hsusubsvh6377、タイトル：BLOGNAME、はauthorName：shakespeareND5}それはまだ構造
で実現でき
TokenMacGuyは、外部キーによって、あなたはポストの "_id" 属性を意味していますか？ 便宜上、重複したデータをコメントオブジェクトに保存しますか？ Backbone.jsで実装しようとしているので、私はBackboneのCRUD操作に備えてこれを本当に考えています。 – AndrewHenderson
はい、親のIDを子の属性に追加することによって、2つのドキュメントを関連付けることになります。しかし、いいえ、非正規化はかなり不便で、通常はパフォーマンスのために行われます。ビューを使用して、couchDBがここであなたを救うかもしれません。 – SingleNegationElimination