私は最初のmongodbプロジェクトに取り組んでおり、Mongodb対relational dbsのスキーマ設計について私の頭を覆そうとしています。Mongodbスキーマ設計のアドバイス
いくつかのRSSフィードから野菜のデータベースを作成したいと思います。これらの飼料のそれぞれには、野菜名のタグがあります。
1）私は2取得は
2）3は、野菜栽培のための飼料野菜の栄養情報/農業情報
3）4は、ブログの記事
があるだけで500異なる野菜のフィードのフィードIの情報を取得する。
このシナリオで最高のスキーマは次のようになります。
A）各野菜のためのコレクションを持っていると、サブ栄養の収集、成長しているとブログの記事を持っていますか？
B）栄養情報の収集を1つ、農業情報用とブログ記事用の1つのコレクションを持っていますか？
私はユーザーが主に野菜の名前を照会することを想定していますが、他のフィールドでも照会することができます。
MongoDBはスキーマレスなので、リレーショナルデータベースと同じように考える必要はありません。私はそれが最初に混乱していることを知っています。また、MongoDBは "サブコレクション"をサポートしていません - コレクション内にドキュメント（個々のエンティティ）があります。
私は実際にこれを選ぶでしょう：
C）2つのコレクション。野菜のコレクションは、本質的に、野菜に関する情報だけでなく、成長する/栄養に関する情報を含む複雑な配列構造です。あなたが検索する必要がある各部分についてcreate an indexを確認してください。既に存在するブログエンジンを使用できない場合は、ブログ投稿用の別のコレクションです。
これは、NoSQLの美しさです。インデックス化する限り、各エンティティ（Mongoのケースではドキュメントと呼ばれます）をかなり複雑にすることができます。お役に立てれば。
MongoDBインデックスに注意してください：クエリあたり1つのインデックス**を使用することができます**：各フィールドのインデックスは、わずかに結果セットをわずかに減らすだけではあまり役に立ちません。 – mnemosyn
野菜の栄養情報には何らかの静的情報（「レタスには1kgあたり20kcal」など）が含まれていますか、複数のソースから集計されていますか（この野菜にはさまざまなソースからの栄養情報が12セットあります）成長する情報についても同じ質問。それが静的なら、私はカルバンに同意するでしょう。そうでなければ、私はオプションBに行くだろう。 – mnemosyn
こんにちは、それはいくつかのソースから集約されています。 – CodeMonkeyB