Разрабатываете решение MongoDB?

Question

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

В любом случае, моя система будет выглядеть примерно так:

Properties Available
  Houses
    House A
      123 Pine Street
    House B
      456 Main Street


Realtors
  Sale
    Leads
      Properties
        House A
          123 Pine Street
      People Involved
        Moe Howard
        Larry Fine
        Shemp Howard
    Budgets
      Operating Budget Items
        $200 rentals
        $400 supplies

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

Другая коллекция - "Риэлторы".

Теперь, в моем старом мире СУБД, я бы создавал таблицы для потенциальных клиентов, людей, бюджетов и т. Д. Однако я думаю, что лучше хранить всю информацию в одной гигантской «записи». Запись «Продажа» будет работать некоторое время (возможно, недели), а затем будет закрыта. Для меня, хранить все в одной записи - это круто. Тем более, что внутри будет храниться очень общая и динамичная информация, такая как веб-сайты, заметки, фотографии и т. Д.

Подхожу ли я к этому с правильным мышлением? Мне трудно отказаться от реляционной модели.

Спасибо за любые предложения и советы.

Answer 1

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

Реляционная модель отлично подходит для проектирования хранилищ с минимальной избыточностью и поддерживает самый широкий диапазон запросов.

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

См. TANSTAAFL .