Выявление шаблонов доступа для приложения

  • 3 мин

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

В Azure Cosmos DB для NoSQL документы называются элементами и контейнерами часто называются коллекциями.

Выявление шаблонов доступа для сущностей клиентов

Начнем с сущностей клиентов в базе данных электронной коммерции. На следующей диаграмме показаны три сущности и связи между ними. Три сущности: Customer, CustomerAddress и CustomerPassword. Сущность Клиента имеет отношение "1:Многие" к CustomerAddress. Клиент имеет отношение 1:1 к CustomerPassword.

Схема, показывающая реляционную модель для сущностей клиента.

В нашем приложении мы будем выполнять три операции с сущностями Customer.

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

Для каждой из этих операций нам потребуются все эти данные одновременно. Если они были моделировались в виде отдельных документов, для создания, обновления и извлечения данных клиента потребуется несколько циклов. Это неэффективно.

Моделирование сущностей клиентов

Azure Cosmos DB хранит данные в формате JSON, поэтому мы можем создавать модель связи 1:Многие между клиентом и адресом клиента и встраивать данные об адресе клиента в виде массива. Для связи 1:1 между Customer и CustomerPassword мы можем внедрить это в качестве объекта в наш новый единый документ клиента. Затем приложение электронной коммерции сможет создавать, изменять или извлекать данные клиента одним запросом.

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

Схема, показывающая модельный документ клиента.