Моделирование данных документа и производительности запросов

Question

У меня сложилась модель данных (представьте, что сущность Customer с виджетами, которые принадлежат им, представляет собой список встроенных сущностей).

Когда я ищу клиентов (например, DocumentDBRepository.GetItemsAsync), которые будут увлажнятьмодель данных клиента вместе с виджетами для каждого.Из соображений эффективности мне не нужен поиск клиентов для рассмотрения виджетов.

Существуют ли какие-либо стратегии для этого в документах dbs (например, в объекте LiteCustomer)?Я подозреваю, что это не просто природа данных «без схемы», о которых я говорил, чтобы хранить их в первую очередь, но мне интересно услышать мысли.

Это просто «не проблема»?

Answer 1

Во-первых, отказ от ответственности: моделирование данных сложно.Есть много нюансов, и вопрос SO никогда не может охватить весь бизнес, и все остается недосказанным как в Q, так и в A. Серебряных пуль нет.Независимо от того ...

"LiteCustomer"

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

* API-интерфейс предоставляет довольно классные инструменты SQL для составления json для возврата документов.

модель физической памяти может отличаться от модели домена

Рассмотрим сценарии использования.Если многие сценарии работают с клиентом без виджетов (или наоборот), тогда рассмотрите возможность использования виджетов в качестве отдельного документа (документов) в модели хранения .

В DocDB вопрос часто заключается не столько в логике запросов, сколько в том, что ваше приложение ожидает от логики модификации.Запрос, который индексируется, выполняется быстро, и каждый SQL-запрос может легко выполнять преобразования (хотя объединение между документами проблематично).Для C (R) UD - у вас меньше вариантов - это всегда полный документ.Слишком большие документы приведут к более высоким затратам на RU и сложному коду.

Вопросы для рассмотрения:

• Как часто клиенты меняются без изменения количества виджетов / деталей?
• Как часто виджеты меняются без смены клиента?
• Изменяются ли виджеты на клиенте независимо или всегда в виде набора?
• Когда вам нужны обновления транзакций на клиенте + изменения виджетов?
• Как будут выглядеть запросы?Могут ли они быть проиндексированы?

Тест.

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

В случае сомнений создайте множество данных и протестируйте их.