MongoDB は、ドキュメントとテーブルという 2 つの基本モードを考慮します。

ドキュメント モードは、学生のコース選択を例として、学生が選択したすべてのコースをドキュメントに記録します。分割テーブル モードは、学生とコースが分離されるリレーショナル データベースのようなものです。を別の表に分割し、学生とコース（コース選択）の対応表を作成します。

ドキュメントの主な利点は読み取り効率が高いことです。MongoDB がテーブルに分割されている場合、各クエリには複数のテーブルが含まれ、複数のクエリが必要になります。このドキュメントの主な欠点は、メンテナンスが不便であることです。たとえば、コースの情報を変更する場合、そのコースを含むすべての学生ドキュメントを検索し、1 つずつ変更する必要があります。さらに、ドキュメントのサイズには制限があり、データを無制限に追加することはできません。 joint

サブテーブルの長所と短所はドキュメント型とは逆になります。

実際には、選択を検討する必要があります。主に読み取られるデータはドキュメント モードを選択する傾向があり、書き込み/変更頻度が高いデータはテーブルの分割を検討する必要があります。さらに、データが無限に増加する可能性があるフィールドの場合は、通常、別のテーブルへの格納を考慮する必要があります。

通常はこの2つを組み合わせて使用​​し、閲覧頻度の高い情報を文書に記録し、それ以外の詳細な情報は別途作成します。この例では、学生とコースに対して 2 つのテーブルが作成され、コース選択の基本情報 (コース コードや名前など) が各学生ドキュメントの下に記録され、各コースの特定の情報がコース テーブルに保存されます。

学生のコース選択情報をリストするたびに、1 つのクエリですべてのコース選択のコードと名前をリストできます。特定のコースの詳細情報を表示する必要がある場合は、コース スケジュールで別のクエリを実行します。これにより、完全なテーブル分割に比べて 1 つのクエリを節約でき、完全なドキュメント記録に比べてドキュメントのサイズとコース情報を変更する際の変更範囲が削減されます。

コースを削除したい場合は、まずコーススケジュールでこのコースのドキュメントを削除し、次に学生テーブルでこのコースを含むすべてのレコードを見つけて変更します。インデックスと演算子を柔軟に使用しても問題ありません。