4

頭を包み込もうとしていCouchDBます。の概念が私にとってより魅力的だと思うので、私はMongoDBに切り替えようとしています。すべてのレコードが単一のデータベースに保存されているように見えます。のように、コレクションなどの概念はありません。では、ユーザー、ブログ投稿、コメントなどのさまざまなデータエンティティを保存する場合、マップリデュース関数内からそれらをどのように区別しますか？ある種のプロパティを使用することを考えていたので、アイテムごとに、常にを指定する必要がありました。この考え方は、クックブックのWebサイトを読んだときに、ある意味強化されました。このWebサイトでは、例で同じことが行われます。CouchDBviewsCouchDBMongoDBtypetypeCouchDB

これはこれを行うための最も信頼できる方法ですか、それともより良い方法がありますか？私は別の方法を考えていましたが、他の唯一の方法は、基本的に可能な限り論理的なドキュメントに埋め込むことだと思います。同様に、データベース内のイミディエイトレコードはすべてUserレコードであり、それぞれUserにの配列がありPosts、そこにすべてを追加するだけですPosts。ここでの欠点は、埋め込まれたドキュメントが独自のidプロパティを取得できないことです。

4

1 に答える 1

7

を作成するときの使用typeは便利で高速viewsです。または、JSONドキュメントの一部の使用を検討することもできます。つまり、定義する代わりに：

{
    type: "user",
    firstname: "John",
    lastname: "Smith"
}

あなたは持っているでしょう：

{
    user: {
        firstname: "John",
        lastname: "Smith"
    }
}

そして、user以下を使用する代わりに、情報を含むドキュメントを発行するためのビューで：

function (doc) {
    if (doc.type === "user") emit(null, doc);
}

あなたは書くでしょう：

function (doc) {
    if (doc.user) emit(null, doc);
}

ご覧のとおり、大きな違いはありません。すでにお気づきのように、1番目のアプローチが最も広く使用されていますが、2番目のアプローチ（afaik）は広く受け入れられています。

Posts1つすべてを1Userつのドキュメントに保存するという問題について。ドキュメントの更新方法によって異なります。更新するたびに（を使用しない限りattachments）ドキュメント全体を作成する必要があることに注意してください。つまり、ユーザーが新しいものを作成するたびに、のPostを含むドキュメントを取得し、1つの要素を追加/変更して、ドキュメントを更新する必要があります。おそらく多すぎる（重い）。arrayPosts

于 2012-12-07T23:49:48.993 に答える