Отношения MongoDB для объектов

Question

Пожалуйста, извините за мой английский, я все еще пытаюсь освоить его.

Я начал изучать MongoDB (из C #) и мне нравится идея MongoDB.У меня есть некоторые проблемы с примерами в Интернете.

Возьмите пример популярного блога / комментария.У поста нет ни одного или нескольких комментариев, связанных с ним.Я создаю объект Post, добавляю несколько объектов Comment в IList в Post.Это прекрасно.

Добавлять ли это просто в коллекцию "Posts" в MonoDB или у меня должно быть две коллекции - одна это blog.posts и blog.posts.comments?

У меня естьДовольно сложная объектная модель, проще всего думать о ней как о банковской системе - наша - майнинг.Я попытался выделить таблицы квадратными скобками.

[Пользователи] имеют один или несколько [Счета] , которые имеют один или несколько [уже] который имеет один и только один [Тип] . [Транзакции] может иметь один или несколько [Tag] , назначенных для транзакции. [Пользователи] создают свои собственные [Теги] , уникальные для этой учетной записи пользователя, и нам иногда нужно предлагать отчеты по этим тегам (например, за май затраты на бурение тегов составляли 123456,78 долл. США).

Для индексации я бы подумал, что разделять их было бы хорошо, но я боюсь, что это плохая практика со старых дней RBDMS.

В каком-то смысле это похоже на пример блога.Я не уверен, должен ли я иметь 1 [Account] Collection и сохранять всю информацию там, или иметь промежуточный шаг, который разбивает ее на отдельные коллекции.

Другой связанный запрос:, когда вы настаиваете взад и вперед, вы обычно получаете обратно все , связанное с этой записью - даже если это не требуется или вы ограничиваете?

Answer 1

Это зависит.

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

Это зависит от отношений - является ли учетная запись пользователя отношением «один ко многим» или «многие ко многим»? Если это один ко многим, а количество учетных записей невелико, вы можете поместить их в список IList в документе пользователя.

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

Вы можете индексировать массивы INTO по документам. Не думайте, что индекс - это просто индекс простого поля в документе (например, SQL). Вы можете использовать, скажем, коллекцию тегов в документе и индексировать теги. (См. http://www.mongodb.org/display/DOCS/Indexes#Indexes-Arrays)

При получении или записи данных вы можете выполнять частичное чтение и частичную запись любого документа. (см. http://www.mongodb.org/display/DOCS/Retrieving+a+Subset+of+Fields)

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

Еще одна проблема: вы упоминаете вычисление итогов по тегам. Если вам нужна согласованность транзакций с бухгалтерским качеством, MongoDB может оказаться не лучшим выбором для вас. «Eventual-консистентность» - это название игры для хранилищ данных NoSQL, и они обычно не подходят для финансовых транзакций. Например, не имеет значения, видит ли один пользователь сообщение в блоге с 3 комментариями, а другой - 4, потому что они сталкиваются с разными копиями реплик, которые еще не синхронизированы, но для финансового отчета такая согласованность имеет значение - ваша отчет может не складываться!