3 ms·

I build most of my apps this way. The main idea is that any time users can add content, it goes into its own collection. This way, records don't grow indefinite

I build most of my apps this way. The main idea is that any time users can add content, it goes into its own collection. This way, records don't grow indefinitely (and hit the 4mb limit) but it also gives you a lot more querying power. You sometimes want to just get the blog post object too, not all the comments. It's worth it to have to do two queries and get the extra selection power vs one round trip to the DB, but you have to potentially sift through a lot of data to get what you want (or get back a lot of data you don't need). This is, in my opinion, the perfect mix of the relational/document schemes. You can nest things when they don't grow continuously, but you still get most of the querying power of a relational database.

aviv 15y ago
Just a quick correction - the default document limit has been 16mb for quite some time now.
kgtm 15y ago
> You sometimes want to just get the blog post object too, not all the comments. I feel this should be clarified a bit (since you most likely have a more complicated scenario in mind) but it is entirely possible to only select certain fields to be returned from a query. So if a 'comments' document was inlined within a 'post' document, we could easily opt to only have the latter returned by mongod. Such a query might look like this: db.posts.findOne( {'_id' : <...>}, { comments:0} ); This would definitely cut down on the amount of data transferred over the wire, but I am not sure if there is any performance hit within mongod.
deleted 15y ago
[deleted]