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

  • 3 мин

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

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

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

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

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

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

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

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

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

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

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

Схема, на которой показана модель документа клиента.