GAE Datastore: нормализация?

Question

Нормализация не в общем смысле реляционной базы данных в этом контексте.

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

Я все еще довольно новичок в хранилище данных, и я знаю, что вы можете запрашивать свойства, вам нужно захватить ключ сущности предка, чтобы пройти вниз ..., поэтому мне интересно, какая из них лучше, а «писать»/read/etc "wise.

Должен ли я сделать:

Вариант 1:

• Пользователь (Entity, предок ReportBundle): информационные свойства общего пользователя
• ReportBundle (Entity, предок Отчета): временная метка
• Report (Entity): общие данные свойства

Вариант 2: свойства информации вставки общего пользователя

Report (Entity)::

• пользователя (сущность, предок отчета) временной метки собственности и обобщенные данные свойства

Answer 1

Do вариант 2:

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

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

Как уже упоминалось из Криса и в комментариях, использование datastore означает мышление денормализованное.

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

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

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

Зная это, и если доступны только эти 2 варианта, вариант 2 будет лучшим.

Answer 2

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