4 ms·

Writing SQL migrations is not easy, I agree with that. But I don't think the issue is with SQL: in my opinion migrations _in general_ are difficult to do proper

Writing SQL migrations is not easy, I agree with that. But I don't think the issue is with SQL: in my opinion migrations _in general_ are difficult to do properly , regardless of the technology, expecially Even when you use a schemaless db like MongoDB, you still have to manage your data (let's say the schema is implicit). If for example you decide that the "phone number" field is no longer a string but a list of objects (containing each the phone number and the kind of number), you will have to update the old data to adapt it to the new model, incurring in the risk of messing up production data. Of course you can (and it is what many people do) avoid the problem at the data level and "fix it" at the application level (for example, checking every time if you have a single string or the new list), but if you really want you can do the same with a SQL database (keep the "phone" field on the table, but add the new table for the list of numbers). A disadvantage of the SQL approach is that many are less versed in it than in the application language, but there are many tools available to handle SQL migrations in your framework's language.

candiodari 9y ago
> Even when you use a schemaless db like MongoDB, you still have to manage your data (let's say the schema is implicit). Yes, the "secret" to MongoDB not having to write data migrations is simple: you get to simply have them as technical debt for later. What could go wrong ? Well, that's easy too: an accounting system where each method has a switch with 10+ cases, each case having 30+ lines of code inside of it, depending on something like "record version" or worse, on implicit tests. And what could be worse ? Well, having a switch with only 9 cases in one of those methods ...
rockostrich 9y ago
> Of course you can (and it is what many people do) avoid the problem at the data level and "fix it" at the application level (for example, checking every time if you have a single string or the new list), but if you really want you can do the same with a SQL database (keep the "phone" field on the table, but add the new table for the list of numbers). This is essentially how my team handles things while using HBase as our main DB. At first it felt weird to not write a migration at the DB level and maintaining compatibility is certainly something that you have to keep in mind at all times, but we have a pretty solid internal library for handling de/serialization in Scala. > A disadvantage of the SQL approach is that many are less versed in it than in the application language, but there are many tools available to handle SQL migrations in your framework's language. I was surprised by this at my previous job. One of the first things I learned about when starting to do web development was database migrations (Miguel Grinberg's Flask tutorial). Sure, I had to learn Alembic when I started the job, but it's a pretty straight forward API and the main issue was the lack of transactional DDL in MySQL that we constantly had to keep in mind. Besides that it was just writing SQL statements wrapped in Python.

candiodari 9y ago

> Even when you use a schemaless db like MongoDB, you still have to manage your data (let's say the schema is implicit). Yes, the "secret" to MongoDB not having to write data migrations is simple: you get to simply have them as technical debt for later. What could go wrong ? Well, that's easy too: an accounting system where each method has a switch with 10+ cases, each case having 30+ lines of code inside of it, depending on something like "record version" or worse, on implicit tests. And what could be worse ? Well, having a switch with only 9 cases in one of those methods ...

rockostrich 9y ago

> Of course you can (and it is what many people do) avoid the problem at the data level and "fix it" at the application level (for example, checking every time if you have a single string or the new list), but if you really want you can do the same with a SQL database (keep the "phone" field on the table, but add the new table for the list of numbers). This is essentially how my team handles things while using HBase as our main DB. At first it felt weird to not write a migration at the DB level and maintaining compatibility is certainly something that you have to keep in mind at all times, but we have a pretty solid internal library for handling de/serialization in Scala. > A disadvantage of the SQL approach is that many are less versed in it than in the application language, but there are many tools available to handle SQL migrations in your framework's language. I was surprised by this at my previous job. One of the first things I learned about when starting to do web development was database migrations (Miguel Grinberg's Flask tutorial). Sure, I had to learn Alembic when I started the job, but it's a pretty straight forward API and the main issue was the lack of transactional DDL in MySQL that we constantly had to keep in mind. Besides that it was just writing SQL statements wrapped in Python.