ユーザー 多くのプロジェクトを持つことができます （プロジェクトは1人のユーザーにのみ関連付けられます）。これは1対多です 関係。
すべてのユーザー 彼/彼女のプロジェクトのリストを保存する必要があります 。例：
user:
id: <some value>,
name: <some value>,
email: <some value>,
projects: [
{ projectId: <some value>, projectName: <...>, projectDescription: <....>, otherInfo: { fld1: <...>, fld2: <...>, etc. } },
{ projectId: <some value>, projectName: <...>, projectDescription: <....>, otherInfo: { fld1: <...>, fld2: <...>, etc. } },
...
]
各プロジェクトに注意してください projects 内のサブドキュメント（オブジェクトまたは埋め込みドキュメント）です 配列。 プロジェクト projectIdなどの関連する詳細があります 、 projectName 、など。
コレクションは1つだけあるべきだと思います user_projectsと呼ばれます 。 （i） user 0〜100のプロジェクトがあり、（ii）プロジェクト の詳細はそれほど大きくありません。
これは、1対Nの関係の「多くの」側を「1つの」側に埋め込むモデルです。これは、データを非正規化するための推奨される方法です。これには、効率的で高速なクエリという利点があります。これにより、同じコレクション内のドキュメントへの1回の操作で書き込み（挿入、更新、削除）がアトミックになるため、トランザクションが簡素化されます。
userを使用します id またはname （一意のインデックスを使用して）ドキュメントを取得します。これは非常に高速なクエリになります。 プロジェクトにインデックスを付けることができます 配列（配列フィールドのインデックスはマルチキーインデックスと呼ばれます ）-プロジェクトのフィールド。たとえば、 projectIdのインデックス または/およびprojectName 理にかなっています。
ユーザーのすべてのプロジェクトを取得できます-userを使用した簡単なクエリ id /名前 。クエリプロジェクション projectに関連する情報を許可します 表示されています。 findを使用できます またはaggregate クエリを作成するメソッド。特定のプロジェクトにクエリを実行できます。 userの場合 、 projectIdを使用 またはprojectName 。 userにインデックスがあるので およびproject フィールドの場合、これは効率的なクエリになります。
したがって、私の推奨事項は、単一のコレクション user_projectsを持つことです。 、 user の情報とプロジェクト そこに埋め込まれた情報。