MongoDB, C# и норма + денормализация

Я пытаюсь использовать MongoDB, C# и норма для работы над некоторыми образцами проектов, но на данный момент мне гораздо сложнее обернуть голову вокруг модели данных. С данными РСУБД проблем нет. В MongoDB, однако, у меня возникли трудное время принятия решения, что с ними делать.

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

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

каков наиболее эффективный способ выполнения отношений с пользователем, не вызывая тонны запросов на каждой странице груз? Я заметил DbReference<T> введите норму, но еще не нашли отличный способ ее использовать. Что делать, если у меня есть nullable необязательные отношения?

Спасибо за ваше понимание!

4 ответов


Я думаю, вам нужно найти баланс.

на вашем месте я бы просто ссылался на userid вместо их имени / репутации в каждом сообщении.

В отличие от РСУБД, вы бы предпочли иметь комментарии, встроенные в документ.


баланс, который я нашел, использует SQL в качестве нормализованной базы данных и Mongo в качестве денормализованной копии. Я использую ESB, чтобы синхронизировать их друг с другом. Я использую концепцию, которую я называю "подготовленные документы"и" сохраненные документы". Сохраненные документы-это данные, которые хранятся только в mongo. Полезно для данных, которые не являются реляционными. Подготовленные документы содержат данные, которые могут быть перестроены с использованием данных в нормализованной базе данных. Они действуют как живые тайники - их можно перестроить из царапина, если данные когда-либо выпадают из синхронизации (в сложных документах это дорогостоящий процесс, потому что эти документы требуют много запросов для перестроения). Они также могут обновляться по одному полю за раз. Сюда приходит служебный автобус. Он реагирует на события, отправленные после обновления нормализованной базы данных, а затем обновляет соответствующие подготовленные документы mongo.

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

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

Я бы обработал пример Stackoverflow, который вы дали, чтобы сохранить идентификатор пользователя в каждом комментарии. Вы загрузили бы сообщение, в котором были бы все комментарии. Это один вопрос.

затем вы пересечете данные комментариев и вытащите массив идентификаторов пользователей, которые вам нужно загрузить. Затем загрузите их как пакетный запрос (используя оператор запроса Q. In ()). Всего два запроса. Затем вам нужно будет объединить данные вместе в окончательную форму. Существует баланс, который вам нужно установить между тем, когда это делать, и когда использовать что-то вроде ESB для ручного обновления каждого документа. Используйте то, что лучше всего подходит для каждого отдельного сценария данных структура.


Почему вы хотите избежать денормализации и обновления "тысяч записей документов"? MongoDB db предназначен для денормализации. Stackoverlow обрабатывает миллионы различных данных в фоновом режиме. И некоторые данные могут быть устаревшими в течение некоторого короткого периода, и это нормально.

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

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

также я предлагаю взглянуть на CQRS и архитектура.


исследование CQRS и мероприятия источники архитектура. Это позволит вам обновить все данные по очереди.