4 ms·

Not sure I understand the MongoDB hate here. Migrations and denomalization is not somthing you have to deal with in MongoDB.

Benjamin_Dobell 8y ago
You almost certainly still need to worry about migrations. MongoDB can store data in a schemaless fashion, however, chances are your application has a data model (schema). Sure, you can avoid migrations and just tack on more and more backwards compatibility for old data layouts. But performance suffers, and chances are that code quality and correctness suffer too.
- __david__ 8y ago
  From a certain perspective, adding backwards compatibility for old data layouts is a migration. A migration that gets run every the data is loaded instead of once during a classic db migration. This is inefficient in the long run.
- hartator 8y ago
  You have to deal migrations maybe 1/20 the times than with SQL. Like no migrations for new tables, new db, and new columns. Column name changes can be handled on the application side or yes with a migration.
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 ago
  Denormilization 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 ago
    As 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 :)
ricklepick 8y ago
This is not totally accruate. Yes, you still have to deal with migrations. When you change the data model, you have to compensate, either with modifying the underlying data or by compensating for it in code. "denormalization" is really just structuring your data model for best performance for your underlying data store and code algorithms. And you most certainly have to do this in mongodb as well. The great thing about using migrations is you pay this price once, at upgrade time. Not in yoru code on every query to the data layer.

Benjamin_Dobell 8y ago

You almost certainly still need to worry about migrations. MongoDB can store data in a schemaless fashion, however, chances are your application has a data model (schema). Sure, you can avoid migrations and just tack on more and more backwards compatibility for old data layouts. But performance suffers, and chances are that code quality and correctness suffer too.

__david__ 8y ago
From a certain perspective, adding backwards compatibility for old data layouts is a migration. A migration that gets run every the data is loaded instead of once during a classic db migration. This is inefficient in the long run.
hartator 8y ago
You have to deal migrations maybe 1/20 the times than with SQL. Like no migrations for new tables, new db, and new columns. Column name changes can be handled on the application side or yes with a migration.

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 ago
Denormilization 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 ago
  As 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 :)

ricklepick 8y ago

This is not totally accruate. Yes, you still have to deal with migrations. When you change the data model, you have to compensate, either with modifying the underlying data or by compensating for it in code. "denormalization" is really just structuring your data model for best performance for your underlying data store and code algorithms. And you most certainly have to do this in mongodb as well. The great thing about using migrations is you pay this price once, at upgrade time. Not in yoru code on every query to the data layer.