ネストされた情報のためのより良いmongodbデータモデル

IMO、各モデル設計には独自の長所と短所があります。「より良い方法」とは、ユースケースによって異なります（データのクエリ方法？最初にすべてのデータが必要ですか？ページングが必要ですか？など）。 。）

要件から始めましょう。

あなたの要件

1. 大学IDを指定して、この大学の学生を見つけます。
2. 学生IDを指定して、彼の大学IDを調べます。

オブジェクト間の関係

1つの大学には多くの学生がいますが、各学生は1つの大学にしか滞在できないため、明らかに大学と学生は1：mマッピングです。

いくつかの異なるモデルデザインを紹介し、各モデルの長所と短所も示します。

アプローチ1-学生を大学に埋め込む

これはあなたが単一のコレクションとして言及したデザインです。

{
   "collegeid":1234,
   "Name":"aaaa",
   "otherinfo":1,
   "studnet":[
      {
         "stdid":1,
         "name":"n1"
      },
      {
         "stdid":2,
         "name":"n2"
      }
   ]
}

長所：

1. 人間が読み取り、フロントエンドが表示するための非常に自然なモデル。
2. 大学とその中のすべての学生をロードするときの良いパフォーマンス。エンジンに保存されているデータは連続しているためです。エンジンはそれを行うためにより少ないI / Oを必要とします。

短所：

1. 大学に膨大な数の学生がいる場合、ドキュメントのサイズは非常に大きくなります。学生を頻繁に追加/削除/更新すると非効率になります。
2. 要件（2）を達成するための迅速な方法はありません。大学->学生からのマッピングのみを維持するため、すべてのドキュメントを調べて、指定されたstudentIDが含まれている大学を見つける必要があります。

アプローチ2-学生は大学に言及している

これはあなたが2つのコレクションとして言及したデザインです。これはRDBMSテーブルに似ており、学生モデルはその大学への参照キーポイントを所有しています。

1. カレッジコレクション：

{
   "collegeid":1234,
   "Name":"aaaa",
   "otherinfo":1
}

2. 学生コレクション：

{
   "collegeid":1234,
   "stdid":1,
   "name":"n1"
}
{
   "collegeid":1234,
   "stdid":2,
   "name":"n2"
}

長所：

1. 要件（1）および（2）を達成できます。インデックス"collegeid"と"stdid"フィールドを追加することを忘れないでください。
2. すべてのドキュメントを小さなサイズで管理できるため、エンジンがデータを簡単に保存できます。

短所：

1. 大学と学生は分かれています。大学とそのすべての学生をロードする場合、アプローチ1よりも遅くなります（2つのクエリが必要です）。
2. UIに表示する前に、大学と学生を自分でマージする必要があります。

アプローチ3-大学と学生の重複データ

このアプローチは、アプローチ1とアプローチ2を混同しているように見えます。2つのコレクションがあります。大学では、学生がそれ自体に埋め込まれ、別の学生コレクションもあります。したがって、学生データは両方のコレクションで複製されます。

1. カレッジコレクション：

{
   "collegeid":1234,
   "Name":"aaaa",
   "otherinfo":1,
   "studnet":[         // duplicated here!
      {
         "stdid":1,
         "name":"n1"
      },
      {
         "stdid":2,
         "name":"n2"
      }
   ]
}

2. 学生コレクション：

{
   "collegeid":1234,
   "stdid":1,
   "name":"n1"
}
{
   "collegeid":1234,
   "stdid":2,
   "name":"n2"
}

長所：

1. アプローチ1とアプローチ2のすべての長所があります。

短所：

1. 大学のコレクションのドキュメントは非常に大きくなります。
2. 大学のコレクションと学生のコレクションのデータを自分で同期しておく必要があります。

アプローチ4-大学（studentIDのみ）と学生の重複データ

これはアプローチ3の変形です。ユースケースは次のとおりであると想定しています。

1. ユーザーは大学を検索できます。
2. ユーザーが検索結果で1つの大学をクリックします。
3. 新しいUIは、すべての学生IDをユーザーに表示します（グリッドまたはリストに表示される場合があります）。
4. ユーザーは1つの学生IDをクリックします。
5. システムは指定された学生の完全なデータをロードし、別のUIでユーザーに表示します。

簡単に言うと、ユーザーは最初はすべての学生の完全なデータを必要とせず、学生の基本情報（学生IDなど）が必要なだけです。ユーザーがそのようなシナリオを受け入れる場合は、以下のモデルを使用できます。

1. カレッジコレクション：

{
   "collegeid":1234,
   "Name":"aaaa",
   "otherinfo":1,
   "studnetIds":[1, 2]  // only student IDs are duplicated
}

2. 学生コレクション：

{
   "collegeid":1234,
   "stdid":1,
   "name":"n1"
}
{
   "collegeid":1234,
   "stdid":2,
   "name":"n2"
}

大学にはスタッドネットIDしかありません。これがアプローチ3との違いです。

長所：

1. 要件（1）および（2）を達成できます。
2. 大学のドキュメントが巨大になることを心配する必要はありません。学生IDしか持っていないので。
3. ユーザーが上記のシナリオを受け入れる場合、これはパフォーマンス/複雑さ/データサイズのバランスに関するより良い設計になります。

短所：

1. 特定のユースケースに適しており、将来要件が変更された場合、シナリオが破られ、このモデルは適切ではありません。

概要

1. ユースケースを明確にする必要があります。
2. ユースケースに基づいて、アプローチを比較して、長所と短所を受け入れることができるかどうかを確認します。
3. 負荷テストは重要です！