4 ms·
Schema migrations in SQL
I just wrote a post on my blog about why schema migrations in SQL are hard. http://www.offbytwo.com/index.php/2007/09/10/why-schema-migrations-in-sql-are-hard/ http://www.offbytwo.com/index.php/2007/09/10/why-schema-migr...
I decided to ask and see how folks work around these problems. So how do you manage schema migrations?
- dappelbaum 19y agoRake on Rails.
- aston 19y agoUltimately, I don't think migrations are really that useful in the first place. When you have a schema that's actually being changed often, you're in development mode, and you can afford to lose data. You can also be smart (yourself) about how you make changes to the tables to avoid data loss. If you really do have a need for migration-like functionality, you can make a new database for each major departure. However, eventually you're going to have to reconcile the two, so you'll end up doing what you might have previously no matter what.
- cstejerean 19y agoWhere does development mode end and production mode begin? With the Software as a Service model you can release updates to your code on a biweekly basis. That means the code (and potentially the schema) is always changing. While it is certainly possible to be clever and do things by hand this gets difficult to manage when you have a team of developers and multiple development, testing, staging and production environments. At my current job we use an internal tool that does some of the job but most of the time I want to fallback on using plain files for some data storage because subversion will version and merge it appropriately. I was more curious about whether or not others out there are using better solutions.