4

今後のサイトで CouchDB を使用することを検討していますが、サイトのユーザー評価システムを実装する方法については少し混乱しています。基本的に、コンテンツの各アイテムは、特定のユーザーによって評価されます。これを行う方法として、CouchDB モデルで最も理にかなっているのはどれですか? 最もドライで最も論理的な方法は、3 つの異なるドキュメント タイプ、コンテンツ、ユーザー、および次のような user_rating ドキュメントを持つことだと思います。

{
  ユーザーID：「ユーザーID」
  content_id: "CONTENTID"
  評価: 6
}

次に、マップがコンテンツ ドキュメント ID をキーとするすべてのコンテンツ ドキュメントと user_rating ドキュメントのセットであり、reduce が評価の平均を集計し、コンテンツ ドキュメント ID をキーとするコンテンツ ドキュメントを返すビューを作成します。

それがこれを行う最良の方法ですか？私はまだ CouchDB のベスト プラクティスに関するリソースをあまり見つけていないので、これらすべてについてかなり確信が持てません。

私の結論：以下の受け入れられた回答は、私がほとんど実装しようとしていたものですが、注意してください。ドキュメントは、他のドキュメントプロパティに基づく高度なクエリを面倒にするコンテンツドキュメントIDによってキーを設定する必要があります. このアプリでは、必要に応じて SQL に戻ります。

4

3 に答える 3

8

合理的な考えを持っているようですね。CouchDB は非常に新しいため、ベスト プラクティスが定着するにはしばらく時間がかかると思います。

このような map/reduce のペアは、妥当な出発点となる可能性があります。

地図：

function(doc) {
   if(doc.type='rating' && doc.content_id) {
     emit(doc.content_id, doc.rating);
   }
}

減らす：

function(keys, values) {
   return sum(values)/values.length
}

注意: その関数には、モデルmapに適切な型を追加する必要があります。Rating

{
  type: 'rating',
  user_id: "USERID",
  content_id: "CONTENTID",
  rating: 6
}
于 2009-02-04T11:19:00.990 に答える
1

Couchdb開発者の 1 人であるDamien Katzが同様のプロセスについて説明しているので、Couchdb 関係者が意図したとおりに実行している可能性があります。

于 2009-02-01T19:26:42.550 に答える
0

同様の状況について書きました（ただし、あなたの例よりも簡単です）。私は自分のブログに記事の評価を追加していましたが、CouchDB を使用して評価自体を保存することにしました。あなたは正しい考えを持っていると思います。

ただし、ここに考えがあります。どこかに表示したり追跡したりするなど、誰が何を評価したか気にしますか? もしそうなら、続けてください:)

ratingそうでない場合は、コンテンツ ドキュメントの属性を に更新してみませんか(ユーザーがコンテンツを複数回評価するのを防ぎたい場合+= 1は、おそらくユーザー ドキュメントのrated属性をに更新します)。.push( doc._id )

これにより、ドキュメントの処理が大幅に簡素化され、ページに表示する評価を「読み取る」ときのパフォーマンスが向上します (コンテンツドキュメントが既にあると想定されるため)...これは、評価の実際のプロセスをより高価にするという犠牲を払っています。 (より大きなドキュメントがサーバーに送信されるなど)。

物事が完全に正規化されていないときに、CouchDB (およびその他のキー値データベース) が最高の状態になることがあるように思えます。

于 2009-02-10T19:46:50.017 に答える