MongoDB Nested Design Philosophy

Question

I'm creating a system where a company HAS multiple users, customers etc. I can't decide whether to make "Objects", such as users, a separate collection or embedded documents of a company document.

Company (Object) ->
    Users (Object) ->
        Profile (Object) ->
            ...attrs..
        History (Object) ->
            ...attrs...
    Customers ->
        ...attrs...

I'm stuck in the relational database mind set right now, and not sure the "proper" way to do it with NoSQL. What are your thoughts?

What happens when a double embedded document (like company>users->history) gets ridiculously large?

What are some other cons to the embedded document approach (if any)? Again, I'm biased towards the relational mind-set.

Thanks in advance.

Answer 1

http://www.mongodb.org/display/DOCS/Schema+Design has some advice on Schema Design, there are also various presentations by members of 10Gen like this one: http://dl.dropbox.com/u/205597/sts/sts-04-2012-mongo-and-nosql-schema.pdf

Given the likely number of users in a company and the likely number of history objects I think you'll probably want a separate collection for each of these.