0

動的フォーム データの収集を含むプロジェクトに取り組んでいます。これらのフォームはユーザー定義 (surveymonkey と考えてください) であるため、固定スキーマを定義することはできません。これらのフォームの質問/回答に関するデータが取得され、データベースに保存されます。この回答のレポート/検索 (フィルタリングと集計) が最も重要です。実行可能なアプローチは 2 つあります。

  1. SQL データベースを使用して、各フィールド データを個別の行として格納します。レポート/検索は、SQL を介して行われます。私の懸念は、レポートのために複雑な結合が発生することです。

  2. MongoDB などの NoSQL データベースを使用します。これはスキーマがないため、動的データの保存に最適なようです。ただし、そのレポート機能がどれほど優れているかはわかりません。

ターゲット ユーザーにとっては、map/reduce クエリを定義するよりも、SQL を学習する方が簡単なようです。mongoDB を介してレポート/検索用の UI を構築するのはどれほど簡単でしょうか。

次のような単純なもの - 特定の回答セットを提供したユーザーのリスト。一定期間などにそのようなユーザーは何人ですか?

ありがとう、プルキット

4

1 に答える 1

1

コメントで既に言及されていますが、Mongo のレポート機能と集計フレームワークの map/reduce 機能を確認する必要があることを繰り返します。

Couch と Mongo の両方で map/reduce を行ったので、それらは非常に似ていると言えます。慣れていない開発者にとっては参入障壁であることは間違いありませんが、いくつかの実用的な例を手に入れれば、それほど悪くはありません。

Mongo が map/reduce ジョブをコレクションに出力できることを考えてみてください。これは非常に便利であることがわかりました。これは、ジョブをスケジュールして定期的に実行し、レポートできる場所に出力できることを意味します。開発者が単純な Javascript マップおよびリデュース関数を記述し、プラグインしてスケジュールに従って実行できるようにするフレームワークを作成することは、それほど難しくありません。

集計フレームワークは、SQL から来た開発者にとって非常に理解しやすいものです。まだ学習曲線ですが、map/reduce ほど悪くはありません。アドホックなレポート クエリにはるかに適しており、Couch に匹敵するものはありません。

集計フレームワークにマップするレポート UI を作成することもできますが、map/reduce クエリに対して同様のことをしようとはしません。

于 2013-04-17T17:24:46.143 に答える