最初の質問について：
親に保存されている子IDを操作するためのより良い方法を具体的に求めます。このパターンでなければならない場合、これに対処するためのより良い方法はないと確信しています。
しかし、この問題はリレーショナルデータベースにも存在します。投稿をリレーショナルデータベースに（そのパターンを使用して）保存する場合は、最初にコメントを作成し、そのIDを取得してから、投稿を更新する必要があります。確かに、これらすべてのタスクを1つのリクエストで送信できます。これは、マングースを使用するよりもおそらく効率的ですが、実行する必要のある作業の種類は同じです。
2番目の質問について：
バリアントAに勝る利点は、たとえば投稿を取得して、mongodbにおそらく何百ものドキュメントを通過するように依頼することなく、コメントの数を即座に知ることができることです。
バリアントBに勝る利点は、より多くの参照を保存できることです。 全体ではなく、単一のドキュメント（単一の投稿）のコメントに コメント、mongosの16MBのドキュメントサイズ制限のため。
ただし、欠点は、その構造を維持するのは非効率的であるということです。これはシナリオを紹介するための単なる例であると私は考えています。そのため、これが私が行うことです。ケースバイケースで何を使用するかを決定します。
-
ドキュメントが頻繁に読まれ、あまり書き込まれない場合は、 AND 16MBを超える可能性は低いです。サブドキュメントを埋め込みます。このようにして、1つのクエリですべてのデータを取得できます。
-
複数からドキュメントを参照する必要がある場合 その他のドキュメントおよび データは本当に一貫している必要があります。そうすれば、それを参照する以外に選択肢はありません。
-
複数からドキュメントを参照する必要がある場合 その他のドキュメントしかし データの整合性はそれほど重要ではありませんそして 最初の箇条書きの制限が適用され、次にサブドキュメントが埋め込まれ、データの一貫性を保つためのコードが記述されます。
-
複数からドキュメントを参照する必要がある場合 他のドキュメントはたくさん書かれていますが、あまり読まない場合は、重複データを同期するためにコードを書く必要がないため、コーディングが簡単なので、参照する方がよいでしょう。
>
この特定のケース（投稿/コメント）では、子から親を参照します（子に親を知らせる_id ）は、他の方法よりも保守が簡単であり、直接埋め込まれた場合、ドキュメントが16MBより大きくなる可能性があるため、おそらく良い考えです。確かに、ドキュメントが16 MBを超えないことを知っている場合は、その方法でデータをクエリする方が高速であるため、それらを埋め込む方が適切です。