Подструктуры против плоской структуры данных в MongoDB - NoSQL - PullRequest
Новая
       42

Подструктуры против плоской структуры данных в MongoDB - NoSQL

0 голосов
/ 17 февраля 2019

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

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

{ 
_id: String,
username: String,
firstname: String,
surname: String,
email: String,
street: String,
city String,
zip: Number,
}

или 

{
_id: String,
name: {
    first: String,
    last: String,
    }
email: String,
address: {
    street: String,
    city String,
    zip: Number,
    }
}

Каковы преимущества / недостатки каждой из структур.Есть ли правило, когда использовать подструктуры или когда использовать плоскую структуру?В чем причина одного против другого?

Заранее спасибо!

1 Ответ

0 голосов
/ 17 февраля 2019

В MongoDB представлены различные шаблоны моделирования данных и схемы. Я поделюсь своим опытом, с какими проблемами я столкнулся, и каковы преимущества различных схем БД.Мы обсудим это один за другим ниже:

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

    Например: если вы хотите получить полный адрес, то в случае встроенного документа вам не нужно индивидуально $ поля адреса проекта, и если вы хотите пропустить поле адреса при получении документа, то вам не нужнопропускайте поля адреса по отдельности.

  2. Встроенный (один к одному) VS Встроенный (один ко многим): Поскольку мы обсуждаем преимущества встроенного документа для плоской структуры данных, нов случае, если у наших пользователей более одного адреса, нам нужно использовать встроенные документы с отношением один ко многим.
    Схема определения отношения один к одному и один ко многим выглядит следующим образом:

Схема отношения один-к-одному: 

{
_id: String,
name: {
    first: String,
    last: String,
    }
email: String,
address: {
    street: String,
    city String,
    zip: Number,
    }
}

Схема отношения один-ко-многим: 

  {
    _id: String,
    name: {
        first: String,
        last: String,
        }
    email: String,
    address: [{           // Embedded address doc with one to many relationship
        street: String,
        city String,
        zip: Number,
      }]
  }

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

Например: поскольку в основном мы сталкиваемся сСценарии ifferent при обновлении обоих типов структур данных, поэтому я поделюсь разницей между запросами на обновление.

Чтобы обновить данные, встроенные с отношением один к одному, вы можете просто использовать точечную нотацию.Для обновления данных, встроенных в отношение «один ко многим», вам нужно использовать оператор $.В этом есть два разных случая.Во-первых, если вы хотите обновить определенный элемент вложенного документа, и, во-вторых, если вы хотите обновить все вложенные документы:

Запрос варианта 1 будет (с использованием оператора $ ): 

  db.collection.update(
       { 'address.streent': 'abc' },
       { $set: { "address.$.street": "xyz" } }
  )

Запрос Case 2 будет (с использованием $ [] ): 

  db.collection.update(
       { 'address.streent': 'abc' },
       { $set: { "address.$[]": "xyz" } }
  )
...