Одиночные или множественные объекты в коллекции в DocumentDB

Должен ли быть один объект в коллекции в DB документа?

У меня есть отношение внешних ключей на диаграмме ниже:

Должен ли я создавать две коллекции для сотрудников и других компаний. Или я должен хранить их в одной коллекции?

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

Итак, было бы лучше сбросить оба класса как единый объект, как показано ниже:

{
  "Id": 1001,
  "Industry": "Software",
  "Employees": [
    {
      "Id": 10011,
      "Name": "John Doe",
      "CompanyId": 1001
    },
    {
      "Id": 10012,
      "Name": "Jane Doe",
      "CompanyId": 1001
    }
  ]
}

Какова стандартная практика реализации связанных объектов в DocumentDB?

Ответ 1

Обычно полезно хранить несколько типов сущностей для каждой коллекции. Следует ли хранить типы объектов внутри одного документа или не принимать более подробные сведения.

Как упоминал Дэвид - как моделировать данные немного субъективно.

Сохранение типов сущностей в коллекции

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

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

Сохранение нескольких типов объектов в документе

Сохраняется ли в нескольких документах несколько типов объектов в одном документе. Обычно это относится к де-нормализации (фиксация отношений между данными путем встраивания данных в один документ) и нормализация (захват отношений между данными путем создания слабых ссылок на другие документы) ваши данные.

Обычно де-нормализация обеспечивает лучшую производительность чтения.

Приложению может потребоваться задать меньше запросов и обновлений для выполнения общих операций.

В общем случае используйте де-нормированные модели данных, когда:

имеют "содержит" отношения между объектами
имеют отношения "один к одному" между объектами.
ненормированные данные изменяются нечасто
де-нормированные данные не будут расти без ограничений
де-нормированные данные являются неотъемлемой частью данных в документе

Пример де-нормированной модели данных:

{
  "Id": 1001,
  "Type": "Company",
  "Industry": "Software",
  "Employees": [
    {
      "Id": 10011,
      "Type": "Employee",
      "Name": "John Doe"
    },
    {
      "Id": 10012,
      "Type": "Employee",
      "Name": "Jane Doe"
    }
  ]
}

Обычно нормализация обеспечивает лучшую производительность записи.

Обеспечивает большую гибкость, чем де-нормализация

Клиентские приложения должны выдавать последующие запросы для разрешения ссылок. Другими словами, нормализованные модели данных могут потребовать больше округлых поездок на сервер.

В общем, используйте нормированные модели данных:

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

Пример нормированной модели данных:

{
  "Id": 1001,
  "Type": "Company",
  "Industry": "Software"
}

{
  "Id": 10011,
  "Type": "Employee",
  "Name": "John Doe",
  "CompanyId": 1001
}

{
  "Id": 10012,
  "Type": "Employee",
  "Name": "Jane Doe",
  "CompanyId": 1001
}

Гибридные подходы

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

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

Пример гибридного подхода:

// Author documents:
[{
  "id": 1,
  "firstName": "Thomas",
  "lastName": "Andersen",
  "countOfBooks": 3,
  "books": [1, 2, 3],
  "images": [{
    "thumbnail": "http://....png"
  }, {
    "profile": "http://....png"
  }, {
    "large": "http://....png"
  }]
}, {
  "id": 2,
  "firstName": "William",
  "lastName": "Wakefield",
  "countOfBooks": 1,
  "books": [1, 4, 5],
  "images": [{
    "thumbnail": "http://....png"
  }]
}]

// Book documents:
[{
  "id": 1,
  "name": "DocumentDB 101",
  "authors": [{
    "id": 1,
    "name": "Thomas Andersen",
    "thumbnailUrl": "http://....png"
  }, {
    "id": 2,
    "name": "William Wakefield",
    "thumbnailUrl": "http://....png"
  }]
}, {
  "id": 2,
  "name": "DocumentDB for RDBMS Users",
  "authors": [{
    "id": 1,
    "name": "Thomas Andersen",
    "thumbnailUrl": "http://....png"
  }, ]
}]

Ответ 2

Ваш вопрос немного субъективен, поскольку вы запрашиваете дизайн сущности, и для этого нет единого правильного ответа.

Тем не менее: с более объективной точки зрения: нет ничего, что мешает вам иметь несколько типов объектов в коллекции (например, тип документа Company и тип документа Employee в вашем случае).

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

РЕДАКТИРОВАТЬ Удалена часть о 3-коллекциях на единицу емкости, поскольку эта компоновка была удалена, когда DocumentDB переместился с Preview на Production.