MongoDB Nested Design Philosophy -


i'm creating system company has multiple users, customers etc. can't decide whether make "objects", such users, separate collection or embedded documents of company document.

company (object) ->     users (object) ->         profile (object) ->             ...attrs..         history (object) ->             ...attrs...     customers ->         ...attrs... 

i'm stuck in relational database mind set right now, , not sure "proper" way nosql. thoughts?

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

what other cons embedded document approach (if any)? again, i'm biased towards relational mind-set.

thanks in advance.

http://www.mongodb.org/display/docs/schema+design has advice on schema design, there various presentations members of 10gen one: http://dl.dropbox.com/u/205597/sts/sts-04-2012-mongo-and-nosql-schema.pdf

given number of users in company , number of history objects think you'll want separate collection each of these.


Comments

Popular posts from this blog

jasper reports - Fixed header in Excel using JasperReports -

media player - Android: mediaplayer went away with unhandled events -

python - ('The SQL contains 0 parameter markers, but 50 parameters were supplied', 'HY000') or TypeError: 'tuple' object is not callable -