Когда мы должны использовать встроенные документы в MongoDB?

Question

Я много читал о встраивании в MongoDB, но все еще не знаю, когда его использовать.Я думал о некоторых сценариях:

У меня есть коллекция с именем UserGroups с этими полями:

• _id
• имя

Теперь я хочу добавить пользователя в коллекцию Users:

1. У меня должно быть поле groupName в коллекции Users и обновлениеэто когда коллекция UserGroups получает обновление.

2. Я должен добавить поле groupId в коллекцию Users и выполнить объединение всякий раз, когда я хочу UserGroups.name.

3. Я должен добавить пользовательский документ как внедренный документ в коллекцию UserGroups.

4. Или я должен добавить документ userGroup как внедренный документ вКоллекция пользователей.хотя я не думаю, что мне следует это делать.

Какой вариант я должен использовать?

Answer 1

Из-за гибкости схемы MongoDB разработчикам больше не нужно сначала разрабатывать схему базы данных, т. Е. Диаграмма отношений сущностей .Сначала следует разработать приложение, а затем разработать схему базы данных в соответствии с использованием приложения (запрос, запись, обновления и т. Д.).См. Также Моделирование данных .

По этой причине нет правильного / неправильного ответа при проектировании схемы базы данных.Существуют различные варианты использования MongoDB, и разные приложения могут использовать разные модели.

Когда мы должны использовать встроенные документы в MongoDB?

Не зная точно, как ваши приложения будут взаимодействовать с данными, следующий ответ - всего лишь общие рекомендацииили подходите :

Подарите предпочтение встраиванию, если нет причин не делать этого.

Попробуйте сначала перевести UserGroup в User.Например:

{ userid: 1001,
  name: "Reza Tayebi", 
  group: {id: 10,
          name: "Developer"
  }
}

Когда отношение одно к немногим (не много, не неограничено).

Приведенный выше пример применим, если пользователь можетбыть в одной или нескольких группах.Если их несколько, но меньше 5, вы можете ввести массив.Однако, если пользователь может быть в 20+ или неограниченном количестве групп, вы должны начать рассматривать разделение групп в другую коллекцию.

Когда поиск может происходить вместе.

Если поиск UserGroups всегда связан с пользователем.Например, либо Query some users with their respective groups, либо Query some users given a specific group(s).

Когда обновления могут происходить одновременно.

Если существует вероятность, что вы обновите Users и UserGroups одновременно.Хотя, начиная с MongoDB 4.0, вы можете использовать транзакции с несколькими документами , если Users и UserGroups не внедрены, одна транзакция с документом будет более эффективной.См. Также Атомарность и транзакции .

Когда поле редко обновляется.

Если имя группы редко обновляется в коллекции.Например, если имя группы Developers требуется часто обновлять до Web Developers для всей коллекции Users, то встраивание UserGroups не подходит.

Опять же, выше приведены только общие рекомендации, которые следует учитывать перед проектированием схемы, см. Также следующие ресурсы:

• Блог: 6 практических правил для разработки схемы MongoDBЧасть 1 , Часть 2 и Часть 3
• Примеры моделей данных и шаблоны
• Операционные факторы и модели данных
• Гибридная схема проектирования