0

Mongoid で Ruby on Rails を使ったアプリケーションを作っています。

ドキュメントベースのデータベースを利用するときにデータベーススキーマを設計する方法について、mongoDB と Mongoid gem のドキュメントを読んでいます。私はしばらく頭の中でそれについて調べてきましたが、私が完全に迷っているかどうかを知るために、私よりも経験豊富な人々からの意見を本当に感謝しています:p

とにかく、これが私たちが作成しているアプリケーションの概要です（質問を事実に即したものにするために、できるだけ単純にしようとしました）：

アプリケーションは、次のエンティティで構成されています。

Users, Subjects, Skills, Tasks, Hints and Tutorials.

それらは次のように編成されています。

Subjects consists of a set of 1..n Skills.

Skills consists of a set of Tasks, (sub-)Skills or both (i.e. skills can be a tree
structure, where one main skill (say, Geometry) is the root and other skills are 
child nodes (for instance, the Pythagorean Rule might be a sub-skill)). However, 
all skills, regardless of whether they have sub-skills or not, should consist of 
0..n tasks.

Tasks have a set of 1..n Hints associated with them.

Hints are each associated with a particular task.

Tutorials are associated with 1..n Skills (this skill can be either a root
node or a leaf node in a skill tree). 

Users can complete 0..n Tasks in order to complete 0..n Skills.

ここで、特定のユーザーが完了したスキル/タスクを収集するためにデータベースに呼び出される読み取りクエリと、サブジェクトに関連付けられたさまざまなスキル ツリーを表示するための読み取りクエリが主にあると想像します。主な書き込みクエリは、おそらく次の形式で、さまざまなユーザーとタスクの間の関係に関連しています。

User A completes Task B

など。また、エンティティの数の大きさは、ユーザー > ヒント > タスク > スキル > チュートリアル > サブジェクトのようになると想像します。

現在、これが私たちが念頭に置いている解決策です。

Subject.rb
has_and_belongs_to_many :skills

Skill.rb (uses Mongoid::Tree)
has_and_belongs_to_many :subjects
embeds_many :tasks

Task.rb
embedded_in :skill, :inverse_of => :tasks
embeds_many :hints

Hint.rb
embedded_in :task, :inverse_of => :hints

チュートリアルの実装と、ユーザーとスキル/タスクの接続はまだ開始していませんが、ユーザーとスキル/タスクの関係は必然的に N:N でなければならないと考えています (これはかなり非効率的だと思います)。

この種のアプリケーションにドキュメントベースのデータベースを使用するのは悪い考えですか? そうでない場合、スキーマを改善してできるだけ効率的にするにはどうすればよいでしょうか?

乾杯、テキストの壁でごめんなさい:-)

4

1 に答える 1

0

私の正直な意見では、データの一部が完全に構造化されていない場合を除いて、問題にNoSQLソリューションを使用する必要はないと思います。私はあなたがデータベースの知識を持っているので、MySQL/PostgreSQLなどに精通しているという観点から出かけます。PostgreSQL（または問題の場合はMysql）は、セットアップ、コードの記述、保守、そしておそらく最終的にはスケールアップが容易になると心から信じています。私のNoSQLの見方は、非構造化データセットがあり、その場でフィールドを追加する柔軟性が必要な場合に使用することです。MongoDBを使用する際の落とし穴があります。特効薬ではありません。

いくつかの落とし穴は、たとえば、in()遅いです。mongoに何かを書き込んですぐに読みたい場合は、取得できないことを期待する必要があります（mongoでのシャーディング）。mapreduceは一種の面倒です（で集約フレームワークを試したことはありませんが、Moped有望に見えます。インデックス作成でシャーディングされたコレクションに問題が発生する場合があります）。

于 2013-02-25T21:57:04.770 に答える