3 ms·
The migration comment has already been addressed. "Denormalization is not somthing you have to deal with in MongoDB." What do you mean exactly? If you have a
by world32 8y ago
The migration comment has already been addressed.
"Denormalization is not somthing you have to deal with in MongoDB."
What do you mean exactly? If you have a piece of data, lets say an address, that exists in more than one place as is the mongodb way, you will absolutely have to deal with the fact that you need to now update that data multiple times. So denormalization is very mcuh some you have to deal with in Mongodb.
Just like in a relational database, denormalization has serious consequences and should only be used when the need for performance outweighs the risks of having much more complex code and hence potentially many more hard-to-debug errors.
- hartator 8y agoDenormilization is not the thing because normalization of data in document db just results in what will heavy denormalized SQL. Like the address fields will be document inside the document. Instead of user_address_1_zipcode, you’ll get user: addresses: [ { zipcode: ... } ] }. It seems more elegant to me. But, yes you do have to update everywhere manually.
- orzig 8y agoAs with so many things, the right answer depends on the expected ratio and complexity of of writes, queries and updates. Something that I've come to believe is that developers don't spend nearly enough time gathering process data that would let them make explicit forecasts (even order of magnitude). Once your team has aligned on those forecasts, a bunch of design debates just fall away. If you really want to have fun, start a prediction market - though that might end up creating its own set of debates :)