あなたが与える例は、多対多の関係のほとんどの実際の例と共通して、実際には少数から少数の例です。 関係。あなたは多くのレストランと多くのダイナーを持っているかもしれませんが、セット全体と比較して、どのレストランもダイナーの小さなサブセットしか提供しておらず、ほとんどの個々のダイナーはレストランの小さなサブセットしか訪れていません。リンク密度比が1を大幅に下回る、まばらにリンクされたネットワークのように聞こえます。
しかし、多対多について質問されたので、例としてニューラルネットワークを使用するのはどうですか？ニューラルネットワークはしばしば密なネットワークを形成するため、真の多対多ネットワークを表します。その場合、答えは簡単です-mongoDBを使用しないでください。特定の要件に合わせて調整されたカスタム構造とシリアル化戦略を使用します。結局のところ、真の多対多の関係はほとんどの場合外れ値であるため、特定の扱いを正当化するのです。
そうは言っても、より一般的な少数から少数のモデリング mongoDBでの関係は、豊富なドキュメント構造を犠牲にすることなく実現できます。これを実現する方法は、アクセスパターンによって異なります。
したがって、レストラン/ダイナーネットワークの例では、通常、レストランのダイナーでクエリを実行する場合は、各レストランで保持されるdiner_idの配列を作成します。もう1つの方法は、各ダイナーで保持される一連のrestaurant_idsを意味します。どちらも双方向クエリ機能用です。
mongoDBにはforeign_key制約がないため、注意が必要です。したがって、データの参照整合性を維持するのはユーザーの責任です。
パフォーマンスが最も重要な場合は、IDで参照するのではなく、各ドキュメントにデータを埋め込むことをお勧めします。これは、すべてのデータを1回のヒットでディスクから引き出すことができるため、読み取り用のより高性能なオプションです（書き込み用ではありません）。これは、データの整合性を確保するためにデータ値を更新するときに、より多くの作業を行う必要があることを意味しますが、多くの場合、これは最初に思われるほど恐ろしいことではありません。ダイナーは実際にどのくらいの頻度で名前を変更しますか？また、ドキュメントのサイズによっては、必ずしもドキュメント全体を埋め込む必要がない場合もあります。データのサブセットと、レコード全体を指すIDを追加すると、多くの場合、うまくいきます。
つまり、mongoDBスキーマの設計は、アプリケーションの要件に基づいて行う必要があります。それらすべてを支配する1つのモノリシックリレーショナルDBとは対照的に、さまざまなアプリケーションのさまざまなスキーマ。データの現実は何ですか？アプリケーションは実際にこのデータをどのように使用しますか？保存されているドキュメントオブジェクトの大きさはどれくらいですか？これらの質問に答えると、スキーマは実際にそれ自体を設計します。