IMO ， каждый дизайн модели имеет свои плюсы и минусы. То, что мы говорим «лучший способ», зависит от ваших вариантов использования (Как вы запрашиваете данные? Вам нужны все данные в начале? Вам нужно пейджинг? И т. Д. ...)
Давайте начнем с ваших требований.
Ваши требования
- По номеру колледжа узнайте студентов вэтот колледж.
- Учитывая идентификатор студента, узнайте его идентификатор колледжа.
Отношения между предметами
Очевидно, колледж и студент 1: m картографирование, потому что много студентов в одном колледже, но каждый студент может остаться только в одном колледже.
Я покажу вам несколько различных дизайнов моделей, а также предоставлю за и против для каждой модели.
Подход 1 - Включение студентов в колледж
Этот дизайн вы упомянули как одну коллекцию.
{
"collegeid":1234,
"Name":"aaaa",
"otherinfo":1,
"studnet":[
{
"stdid":1,
"name":"n1"
},
{
"stdid":2,
"name":"n2"
}
]
}
Плюсы:
- Очень естественная модель, удобная для чтения и отображения на экране.
- Хорошая производительностьВо время загрузки колледжа и всех студентов в нем.Потому что данные, хранящиеся в движке, находятся в непрерывном режиме.Для этого двигателю требуется меньше операций ввода-вывода.
Минусы:
- Если у вас в колледже огромное количество студентов, размердокумента будет очень большой.Это будет неэффективно, если вы будете часто добавлять / удалять / обновлять учащегося.
- Нет быстрого способа выполнить требование (2).Поскольку мы ведем сопоставление только от студентов колледжа -> студентов, вам необходимо просмотреть все документы, чтобы выяснить, в каком колледже указан указанный идентификатор студента.
Подход 2. У студента есть ссылка на колледж
Это дизайн, который вы упомянули как две коллекции.Он похож на таблицы СУБД, студент модель имеет ссылочный ключевой момент в его колледже
- коллекция колледжа:.
- Студенческая коллекция:
{
"collegeid":1234,
"stdid":1,
"name":"n1"
}
{
"collegeid":1234,
"stdid":2,
"name":"n2"
}
Плюсы:
- Можно выполнить требования (1) и (2).Не забудьте добавить индекс в поле
"collegeid" и "stdid". - Каждый документ можно хранить в небольшом размере, движок легко сохраняет данные.
Минусы:
- Колледж и студенты разделены.Это будет медленнее, чем в подходе 1, если загружается колледж и все его студенты (нужно два запроса).
- Вам необходимо объединить колледж и студентов самостоятельно, прежде чем отобразить в пользовательском интерфейсе.
Подход 3 - Дублированные данные в колледже и студентах
Этот подход выглядит так, как будто мы смешиваем подход 1 и подход 2. У нас есть две коллекции ： в колледже будут встроены его студенты, а также отдельная коллекция студентов.Итак, данные об учениках дублируются в обеих коллекциях.
- Коллекция колледжа:
{
"collegeid":1234,
"Name":"aaaa",
"otherinfo":1,
"studnet":[ // duplicated here!
{
"stdid":1,
"name":"n1"
},
{
"stdid":2,
"name":"n2"
}
]
}
Студенческая коллекция:
{
"collegeid":1234,
"stdid":1,
"name":"n1"
}
{
"collegeid":1234,
"stdid":2,
"name":"n2"
}
Плюсы:
- У вас есть все плюсы с подхода 1 и подхода 2.
Минусы:
- Документ в коллекции колледжа станет очень большим.
- Вы должны хранить данные из коллекции колледжа и студентасбор Синхронный самостоятельно.
Подход 4 - Дублированные данные в колледже (только studentID) и студентах
Это вариант из Подхода 3. Мы предполагаем, чтоВаш вариант использования:
- Пользователь может искать колледж.
- Пользователь выбирает один колледж в результатах поиска.
- Новый пользовательский интерфейс отображает все идентификаторы студентов для пользователя(возможно, в виде таблицы или списка).
- Пользователь щелкает один идентификатор учащегося.
- Система загружает полные данные указанного учащегося и показывает его пользователю в другом пользовательском интерфейсе.
Одним словом, пользователю не нужны полные данные всех учеников в начале, ему просто нужна базовая информация учеников (например, студенческий билет) .Если пользователь принимает такой сценарий, вы можете иметь модель ниже:
- CollКоллекция ege:
{
"collegeid":1234,
"Name":"aaaa",
"otherinfo":1,
"studnetIds":[1, 2] // only student IDs are duplicated
}
Студенческая коллекция:
{
"collegeid":1234,
"stdid":1,
"name":"n1"
}
{
"collegeid":1234,
"stdid":2,
"name":"n2"
}
В колледже есть только идентификаторы студенческих сетей.Это разница по сравнению с подходом 3.
Плюсы:
- Можно выполнить требования (1) и (2).
- Выне нужно беспокоиться о том, что документы колледжа вырастают до огромных размеров.Так как ему принадлежат только студенческие идентификаторы.
- Если пользователь примет вышеприведенный сценарий, это будет лучше для баланса производительности / комплекса / размера данных.
Минусы:
- Подходит для указанного варианта использования, если требование будет изменено в будущем, нарушит сценарий, и эта модель будет не годной.
Резюме
- Вы должны быть очень понятны с вашими вариантами использования.
- На основе вариантов использования сравните подходы, чтобы увидеть, можете ли вы принимать за и против.
- Нагрузочное тестирование важно!