16.12.05

[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

and some examples:
[... see Databaserefactoring.com]

Some sidenotes:

  • put all DB-stuff under Version Control, including schema generation scripts, triggers, procedures, ...
  • every developer has her own DB schema to easily apply changes to the DB and the code an roll both out at once into integration
  • If you can refactor applications with toolsupport since years, why can't you refactor database schemas? (this reminds me of the trained monkey talk ...)

    If you want to have a refactorable system stick to two rules:

  • any new system has to be refactorable
  • with any code change the touched part should be refactorable

    The DatabaseTools Project at Eclipse might bring some tool support for refactorings.
    For DB-Regression testing there are already some tools like:

  • OUnit
  • Check for C
  • VBUnit
  • DBUnit

    Posted by Karsten at 16.12.05 19:49 | TrackBack
  • Comments
    Post a comment









    Remember personal info?