Data denormalization: conflict between Meteor approach and Document approach

Hello guys, i’m really confused about the paragraph

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

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
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.