MongoDBのスキーマを設計する際の重要な考慮事項は、データが何であるかではなく、それをどのように使用するかです。実行する読み取りと書き込みのタイプ（およびそれらのパフォーマンス）を理解しないと、「最適な」スキーマを設計するのが難しい場合があります。
問題が発生しないようにするために検討できる基本的なガイドラインがいくつかあります。それらの1つは、無制限に成長し続けるドキュメントの設計を避けることです。つまり、注文を顧客ドキュメントに埋め込んではいけません。もう1つのルールは、それ自体では「関心がない」（またはそれ自体では存在しない）ものは、埋め込まれたほうがよいでしょう。これは、orderItemsが独自のコレクションに値するものではなく、単に注文の属性として扱われるべきであることを示唆しています（実際にはそれが何であるか）。
この正確な演習は、MongoDB開発者トレーニングでカバーされており、スキーマ設計の非常に典型的な例です。
結論として、3つのコレクションが必要です。
製品
顧客
注文
注文は顧客を参照し（オプションで顧客コレクションからの一部の情報を非正規化します）、製品を参照します（含まれるorderItemの配列内）。
その他のコレクション、およびこれらすべてのコレクションの正確なフィールドは、特定のユースケースによって異なりますが、これら3つよりもコレクションが少ないという実現可能なシナリオはわかりません。