

Schema migrations in SQL - cstejerean

I just wrote a post on my blog about why schema migrations in SQL are hard. <a href="http://www.offbytwo.com/index.php/2007/09/10/why-schema-migrations-in-sql-are-hard/" rel="nofollow">http://www.offbytwo.com/index.php/2007/09/10/why-schema-migr...</a><p>I decided to ask and see how folks work around these problems. So how do you manage schema migrations?
======
aston
Ultimately, 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
Where 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.

------
dappelbaum
Rake on Rails.

