MongoDB - Денормализация / модельное мнение

Question

Я знакомлюсь с Монго, но, исходя из опыта СУБД, сталкиваюсь с, вероятно, очевидными вопросами, касающимися денормализации и общего моделирования данных.

Если у меня есть тип документа с массивом вспомогательных документову каждого подчиненного документа есть код состояния.

В реляционном мире я бы добавил в запись внешний ключ StatusId, просто.В mongodb вы бы денормализовали ключевые фрагменты данных из «статуса», например, Code и desc, и содержали бы objectid, ссылаясь на другую коллекцию надлежащего статуса.Я предполагаю, что следующий вопрос касается дизайна: если статус документа будет изменен, то мне нужно будет изменить денормализованные данные?

Еще один вопрос на ту же тему: как бы вы смоделировали таблицу транзакций, скажем я?У событий и людей события могут быть весьма гранулированными, скажем, в расписаниях, которые со временем могут привести ко многим записям.Исходя из того, что я видел, это может показаться хорошим кандидатом для дочернего / подчиненного массива документов, конечно, который можно индексировать по скорости.

Следовательно, можно запросить / найти только субмассив или его часть?И учитывая ограничение в 16 МБ для размера документа, и я просто ограничил историю транзакций человека?Или история транзакций должна быть отдельной коллекцией с onjid, ссылающейся на человека?

Спасибо за любой ввод

Сэм

Answer 1

Или история транзакций должна быть отдельной коллекцией с onjid, ссылающимся на человека?

Возможно, я думаю этот вопрос S / O может помочь вам понятьпочему.

если статусный документ изменен, мне нужно будет изменить денормализованные данные?

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

Следовательно, можно ли запрашивать / находить только подмассив или его часть?

Это сложная проблема, специфичная для MongoDB.С базовым синтаксисом запроса у вас есть только ограниченная поддержка для работы с массивами объектов.Новая «структура агрегации» на самом деле намного лучше, но она недоступна в стабильной сборке.

Answer 2

На все ваши «как моделировать то или иное» невозможно ответить, потому что хороший дизайн схемы зависит от многих факторов (схемы доступа, характеристики оборудования, используемый кластер и т. Д.).

если статус документа будет изменен, то мне потребуется модифицировать денормализованные данные?

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

, чтобы запросить / найти только подмассивили его часть?

В настоящее время невозможно извлечь только часть массива (если, конечно, не использовать map / уменьшает).

И с учетом 4mbпредел

Откуда вы это взяли?Сейчас 16 МБ.

Answer 3

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

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

Есть несколько драгоценных камней, которые помогут вам управлять денормализованными данными, включая их настройку и синхронизацию.Если вы используете Mongoid, попробуйте mongoid_alize .ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ: Я являюсь автором и сопровождающим mongoid_alize.