Это правильный способ моделирования данных в MongoDB? - PullRequest
Новая
       12

Это правильный способ моделирования данных в MongoDB?

2 голосов
/ 23 января 2020

Я новичок в моделировании данных и работаю над личным проектом, в котором пользователи могут загружать фотографии в контейнеры. Эти контейнеры могут быть вложенными (например, контейнер «Japan» может иметь вложенный контейнер «Cats», в котором вы можете хранить изображения всех кошек, которых вы видели в Японии).

Я представляю 3 объекта: пользователей, контейнеры и фотографии, структурированные следующим образом:

Коллекция пользователей: 

{
  User_id: userId101,
  userName: “Chase”,
  Email: “chase@email.com”,
  Containers: [{name: “Thailand”, parentContainer: null}, {name: “Food”, parentContainer:
                     “Thailand”],
}

Коллекция контейнеров: 

{
  Id: cont_01,
  Name: “Thailand”,
  ownedBy: userId101
  parentContainer: null,
  Photos: [“photoId1”, “photoId2”, etc.]
{

Коллекция фотографий: 

{
  Id: photo_01,
  userRef: userId101
  Url: “www.unsplash.com/1279178298”
}

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

Большое спасибо :)

1 Ответ

3 голосов
/ 23 января 2020

Здесь действительно можно принять во внимание множество факторов. Прежде всего вам не нужно думать, что каждая «сущность» должна иметь отдельную коллекцию (как в SQL). BSON может обрабатывать вложенные массивы, как показано ниже: 

{
    Id: cont_01,
    Name: "Thailand",
    ownedBy: userId101
    parentContainer: null,
    Photos: [ { id: "photo_01", "www.unsplash.com/1279178298" }]
}

«Объединение» (* 1004) * $ lookup ) данные в MongoDB являются дополнительными издержками, поэтому держите их объединенными, если у вас нет веских причин для разделения на несколько коллекций.

Моделирование данных, как описано выше, дает вам возможность использовать $ graphLookup для получения дерева отношений родитель-потомок.

Это то, с чего я бы начал. В качестве следующего шага вы можете рассмотреть возможность встраивания пользовательских данных в каждый контейнер (денормализованный), чтобы избежать использования $lookups или наличия одного user документа с массивом контейнеров со встроенным photos - более сложно поддерживать (обновления немного больше). сложный, как здесь ), но с лучшей производительностью чтения, так как вам не нужны поиски.

Недостатком очень больших документов также является ограничение размера документа 16 МБ, что очень много, но хорошо иметь это в виду.

...