Проектирование базы данных с MongoDB

Question

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

IЯ делаю приложение для iPhone, где люди могут создать событие, а затем пообщаться о нем (скажем, чтобы прояснить некоторые детали).У меня есть коллекция для событий.Я не уверен, как я должен хранить чаты пользователей, хотя.Я хочу, чтобы чат был связан с соответствующим событием, но я не уверен, как это сделать, учитывая, что MongoDB не является реляционным.

Должен ли я просто создать еще одну коллекцию / документ для чатов и связать (я имею в виду ссылку MongoDB) это событие?

Answer 1

Ключевой вопрос при разработке схемы MongoDB - когда вставлять, а когда связывать.Внедрение - это вложение объектов и массивов в документ BSON.Ссылки - это ссылки между документами.

Так начинается официальная документация по разработке схемы MongoDB .

При проектировании базы данных документов необходимо учитывать несколько моментов:

1. какая сущность является родительской, а какая дочерней?Они действительно связаны?
2. Какая модель доступа является наиболее распространенной для родительского объекта?всегда ли нужно извлекать всех детей?
3. Какая модель доступа является наиболее распространенной для дочерней сущности?Вы обращаетесь к нему по отдельности или большую часть времени вы получаете его вместе с его родителем?
4. как часто вы добавляете дочерний элемент к родителю?
5. эти операции добавления выполняются в высокой степени параллельнойокружающая среда?
6. как часто вам нужно обновлять встроенный документ?

Чтение документа MongoDB, на который я указывал, и ответы на поставленные выше вопросы дадут вам окончательный ответ.*

Answer 2

Я бы вставил чаты в документ события.

Кажется, что чат всегда будет упоминаться в контексте события, и поэтому имеет смысл встроить его внутрь, чтобы его можно былолегко доступны.

Последствия для производительности являются более тонкими.Некоторые вещи, которые следует учитывать:

Если бы вы использовали встроенный подход, то при получении документа чат уже содержался бы в нем.Следовательно, последующий запрос не понадобится для получения чатов.Это ускоряет доступ к чатам, но также потенциально замедляет получение документов событий (поскольку они больше).Однако вы можете исключить ненужные поля (что делает производительность эквивалентной производительности сценария с двумя разными коллекциями)

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

Надеюсь, это поможет, ура!

Answer 3

При проектировании схемы БД всегда учитывайте ограничение на размер документа.Для бесконечно растущих поддокументов лучше всего хранить их в другой коллекции.Это будет справедливо для комментариев, чатов и т. Д. Внутри родительского поста.Надеюсь, это поможет.

Answer 4

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