Data denormalization: conflict between Meteor approach and Document approach

Hello guys, i’m really confused about the paragraph https://guide.meteor.com/collections.html#denormalization

I understand that if a single field is updated in a potentially huge doc, meteor will send the whole doc to the client. (not cool).

And so, to counter this, the guide propose to denormalize the data, but as far as i know Document oriented databases, it’s not their philosophycal approach.

From rules of thumb there https://www.mongodb.com/blog/post/6-rules-of-thumb-for-mongodb-schema-design-part-3?_ga=1.53558189.445719541.1489677957

One: favor embedding unless there is a compelling reason not to
Two: needing to access an object on its own is a compelling reason not to embed it
etc
Five: A field that will mostly be read and only seldom updated is a good candidate for denormalization: if you denormalize a field that is updated frequently then the extra work of finding and updating all the instances is likely to overwhelm the savings that you get from denormalizing.

So, i m not here to “find the truth” but to ask for the point of view of people higher skills than me.

If i have a document, with everything embedded, cause it’s just suit me well, but i need to update quite often a field deep in the doc: am i a little bit fucked?

Thanks for your time ! :slight_smile:

You have it right - to take advantage of Meteor’s live data system in the best way you need to create smaller documents than people sometimes do in MongoDB.