Designing a MongoDB solution?

I'm a RDBMS guy that has a project that I believe will work really well in a MongoDB system. For different reasons that I think is irrelevant for the questions at hand.

Anyway, my system will be something like the following:

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

As you can see, I have two collections. One ("Properties Available") will be generated at different times from different sources and will be shared across any nu开发者_开发知识库mber of users. Most of the content will be static and not change often.

The other collection is "Realtors".

Now, in my old RDBMS world, I would create tables for Leads, People, Budgets, etc. However, I think keeping all of the information in one giant "record" would be better. A "Sale" record would be worked on for a while (weeks perhaps) and then closed. To me, keeping everything inside that one record is awesome. Especially since there will be wildly generic and dynamic information stored inside such as websites, notes, photos, etc.

Am I approaching this with the right mind-set? It's hard for me to let go of the relational model.

Thanks for any suggestions and tips.

One can't answer yes or no that this is the best design for your data. You've described the items you want to store, but not how you intend to query it.

The relational model is great for designing storage that has minimal redundancy, and supports the widest range of queries.

The document-oriented model is great for optimizing specific queries. But you need to know in advance what types of queries you need to be most efficient.

See TANSTAAFL.