私はMongoにはとても新しく、異なるテーブル/コレクション間の関係をいかに正確に捉えなければならないのか理解しようとしています。MongoDBリレーションズ対SQL
例えば、USERと彼のPOST（S）の間の関係。 SQLでは、2つのテーブルを作成し、すべての投稿にUSERのUSERIDを付けます。
モンゴでこれをどうやってやるのですか？ 2つの別々のコレクションを、ユーザー用と投稿用にそれぞれ1つずつ作成しますか？または私は投稿をのようにユーザのコレクション内に埋め込むthis
ありがとう！
すべては、特定のシナリオ、最も重要な使用パターン（最終的にはクエリ）によって異なります。
あなたは、一般的に、別のあなたのアプリケーションとの記事の一つの領域内のユーザを扱う場合は、2つのコレクションにそれらを分割することは確かに（のみ）正しい方法です。
投稿を「ユーザーのコンテキストから」見る必要がある場合は、投稿をユーザー文書にマージすることは有効な方法です。ただし、16MBのドキュメントの制限に注意してください。だから、ある時点でユーザーが16MB以上の投稿を持っていれば、大変な変更が必要な問題があります。
お使いのアプリケーションが一般的に投稿に注目していますが、たとえば、特定の投稿のユーザー名を指定すると、ユーザーデータを投稿とは別に保存できますが、ユーザーの投稿ごとにユーザー名が保存されます。この場合、ユーザーが名前を変更すると、そのユーザーのすべての投稿を2番目のコレクションのメインユーザーレコードの上に更新する必要があります。あなたが完全にMongoDBスタイルになったら、データの重複は一般的に必要不可欠です。
...潜在的な設定に関して、さまざまなグレーの色合いがあります。いいえ、またはひどく間違っています。あなたの場合には、より良く適合します。 ;）私が最初に書いたように、それは書き込みパフォーマンス、読み込みパフォーマンス、使いやすさ/データ使用量やデータアクセスパターンを使って集計したデータの分析の痛みなどの面でトレードオフです...
MongoDBの方法は、USERSコレクションの投稿を埋め込むことです。
もしリレーショナルなやり方をしたいのなら、POSTSコレクションの中にOBJECTIDキーを置き、USERSコレクションのARRAYキーの中のそのOBJECTIDを参照することができます。
ただし、データセットで多くのリレーショナル操作を使用することが予想される場合、MongoDBはこれにアプローチする方法ではない可能性があります。私はPostgresqlを提案します。