Monday, September 11, 2006

Use migrations outside of Rails

If you haven't read Scott Ambler's Agile Database Techniques, I recommend it. I didn't realize how spoiled I was to work on projects where the database could be create by scripts, until I worked on projects where an evil DBA controlled all access to everything. It was some small comfort to see "all access to database through stored procedures" as one of the problems to be handled with legacy systems in the book. I haven't read Refactoring Databases yet, but it's somewhere on my todo list....

The next step, once you have the database scripted is scripting the changes to the database. The Rails ActiveRecord migrations approach is really cool for this, and there is no reason it should be applied outside of Rails, as Dion points out... Basically it gives a way to step back from any change, in addition to scripting each changeset to the database. Beyond all of that, it gives you a database neutral method for describing the database itself, making migration to another database platform more of a possibility.

Is the biggest danger of having a DBA on an Enterprise Application that they are going to write code that locks you into a technology? No- I think the bigger danger is that they are non agile and that they won't know how to deal with changes to the database that occur at the rate agile projects demand.

0 comments: