MongoDB beginner - нормализовать или не нормализовать?

Question

ОК, я постараюсь сделать это как можно прямолинейно, насколько смогу.
пришедшего из MySql и мышления в таблицах, давайте использовать следующий пример:
Допустим, что у нас есть веб-сайт по недвижимости, и мы отображая список домов
нормально, я бы использовал следующие таблицы:
* дома - объект недвижимости под рукой
* владельцы - владелец дома - одноразовые отношения с жилыми домами
* агентства - агентство брокерских недвижимости - отношение много-ко-многим к дому
* images - many-to-one отношения с домами
* отзывы - много-к-одному отношения с домами

Я понимаю, что MongoDB дает вам гибкость в дизайне вашего веб-приложения в разных коллекциях с уникальным идентификатором, похожим на реляционную базу данных (нормализованный), и для быстрого выбора вы можете вложить в коллекцию, связанные объекты и данные (ун-нормированная).
вернуться к списку наших домов, запрос, используемый для его заполнения, довольно дорог в обычной реляционной БД, для каждого дома вам нужно запросить его изображения, отзывы, владельцы агентств &, каждый объект находится в другой таблице, его поля, вы, вероятно, используете объединения и объединяете несколько запросов в один - Дорого!
Введите MongoDB - там, где вам не нужны соединения, и вы можете хранить все связанные данные дома в домашнем предмете в коллекции домов, выбор никогда не был быстрее, это небеса db!
О, но что происходит, когда вам нужно добавлять/обновлять/удалять связанные обзоры/агентства/владельца/изображения?
Это для меня загадка, и, если мне нужно угадать, каждая связанная коллекция существует в собственной коллекции поверх своих данных в таблице домов, и как только одна из этих частей связанных данных добавляется/обновляется/удаляется вам придется обновить его в своей коллекции, а также в коллекции домов.
После этого обновления - нужно ли мне также запрашивать другие коллекции, чтобы убедиться, что обновляю домашнюю запись со всеми обновленными соответствующими данными?
Я действительно предполагаю здесь ... и ценю ваше мнение
Thanks
приоткрыта

Answer 1

Попробуйте этот подход:

Потренируйтесь, какой объект (или объекты) являются герой (ы)

С «героем» я имею в виду объект (ы), в котором находится база данных. Давайте рассмотрим ваш пример. Героем примера недвижимого имущества является дом *.

Отработать домовладения

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

Отработать на самом деле имеет ли это, что данные де нормализованы

Вы будете иметь агентство (и, возможно, владелец) Детали распределены по нескольким домам. Это имеет значение?

Ваш дом коллекция, вероятно, выглядеть следующим образом:

house: { 
owner, 
agency, 
images[], // recommend references to GridFS here 
reviews[] // you probably won't get too many of these for a single house 
} 

* На самом деле, это, вероятно, объявление дома (так как дома, как правило, рекламируемый на сайте по недвижимости, и это, вероятно, что вы действительно заинтересованы), так что просто подумайте, что

Answer 2

Сара Мэй написала информативную статью о проблемах, которые могут возникнуть с целостностью данных в nosql dbs. Выбор между дублирующимися данными или использованием идентификаторов, основанных на кодах и проблем с сохранением целостности данных. Ее мнение состоит в том, что любой nosql db с кодовыми объединениями потеряет целостность данных в какой-то момент. Imho комментарии к статьям столь же ценны, как и сама статья в понимании этих вопросов и возможных резолюций.

Ссылка: http://www.sarahmei.com/blog/2013/11/11/why-you-should-never-use-mongodb/comment-page-1/

Answer 3

Я просто хотел бы дать нормализации освежитель с точки зрения MongoDB «s -

Каковы цели нормализации?

• Освобождает база данных от модификации аномалий - Для MongoDB, это выглядит как вложение данных будет в основном причиной этого. И на самом деле мы должны стараться избегать встраивания данных в документы в MongoDB, которые могут создать эти аномалии. Иногда нам может понадобиться дублировать данные в документах по соображениям производительности. Однако это не подход по умолчанию. По умолчанию следует избегать этого.
• Если минимизировать редизайн при расширении - MongoDB является достаточно гибким, поскольку он позволяет добавлять ключи без повторного проектирования всех документов
• Избегайте смещение к какому-либо определенному шаблону доступа - это то, что мы не беспокоиться при описании схемы в MongoDB. И одна из идей, лежащих в основе MongoDB, - это настроить вашу базу данных на приложения, которые мы пытаемся написать, и проблему, которую мы пытаемся решить.