あなたの挑戦は、 Prop_Info 両方のクエリで取得する必要があります。これにより、どのMongoコレクションに配置する必要があるかを判断するのが困難になります。
MongoDBでは、クエリパターンに必要なすべての情報を単一のドキュメントに含めるという理想的な目標を持って、ドキュメントスキーマを作成します。同じデータが必要な場合D （ Prop_Info など あなたの場合）2つの別々のコレクション Aに対する2つの別々のクエリによって返されます およびB 、次の3つの戦略から選択する必要があります。
-
重複する
D両方のAのドキュメントで およびB、およびコードとの整合性を強制します。これは通常、挿入/更新側でコードがさらに複雑になり、MongoはACIDではないため、一貫性の問題が発生する可能性がある場合でも、2番目のクエリの必要性を排除したい高性能システムの設計上の選択です。 -
Dを置くAで 参照（DBRefまたは識別フィールドの他の組み合わせ）をBに保存します 2番目のクエリでそれに到達できるようにします。これは通常、Aへのクエリの数が設計上の選択です。Bへのクエリ数を超えています 。Dを保持します より頻繁にクエリされるコレクションのローカル。このスキーマデザインパターンでは、Bをクエリするときに、2番目のクエリを実行するだけで済みます。 。 -
Dを置く 新しいコレクションのC両方のAから2番目のクエリを作成します およびB。これは通常、上記の（1）または（2）を使用した場合のトレードオフが明確でない、非常に不確実な将来の要件に直面した場合の設計上の選択です。これは最も「リレーショナルに似た」スキーマであり、両方のAをクエリするときに2番目のクエリを実行するように強制するスキーマです。 およびB。
どの戦略を選択するかは、ドメイン、クエリパターン、オブジェクトリレーショナルマッピング（ORM）フレームワーク（使用する場合）から得られるサポート、そして最後になりますが、好みによって異なります。
私が遭遇した状況では、私は決して選択しませんでした（3）。私は（1）を高性能な状況（分析システム）で使用しました。クエリアクセスパターンにより、「共有」データがどこに存在するかが明確になったため、他のすべての場所で（2）を使用しました。
戦略を選択した後も支援が必要な場合は、選択した戦略に基づいてスキーマ設計の問題に特に焦点を当てた別のSO質問を投稿してください。
最後の3つのヒント：
-
共有データの場合
D関係の多重度が1より大きい場合は、配列を使用します。 <を使用して、配列全体にインデックスを付け、配列内で正確にクエリを実行できます。 code> $ elemMatch 。 -
Dを更新するには 戦略（1）または（2）では、MongoDBのアトミック修飾子を使用します操作 、その多くはアレイ上で動作するように設計されています。 -
このSOの質問 @Stennieの回答のDBRef2クエリパターンについて説明します。 （@Stennieは、MongoDBのマーカーである10genで動作します。）
幸運を！