[JP] Day 5 - DataBase Refactoring

Actually I must confess that I never thought about refactoring in the domain of databases. But it perfectly makes sense.
Scott W. Ambler is a nice presenter (definetly rather the north american style of presenting, but still with good content). So he was raising a lot of questions and interacting with the audience quite nicely.
Why are DB-people feel so important? Why do they need days/weeks to roll out changes to the DB? Why is therefore every developer bypassing them, making them angry although they should start thinking about the reasons for this move.
Data modeling is unsexy, just like Testing was, before the agile community took over this field, raising the bar of expectations, making testing easy and sexy. Best example is JUnit and plenty of other tools in this field.
So the agile community needs to take over and reinvent data modeling.
So if there is a DB guy in you company thinking that DB things are sooooo important ask him about regression test for the DB. Nearly noone has this in that field, but is a best-practice in the developer world.
Referenced integrity is not really an issue of the DB, since you have to keep track of dependecies in you OO-Program as well and there it is quite obvious.
Nevertheless: Data is important!
... Just like UI is important, and network, and security, and business processing, and 10 other things the developers are taking care of.
At Databaserefactoring.com you find further information about how you can refactor a DB.
Scott walked us through the general procedure:

1. First of all you introduce the new schema
   
2. keeping the old one alive for a certain period and mark it as deprecated (no Toolsupport!!)
   
3. keep both (old and new style) in sync via triggers

Some sidenotes: