Database Refactoring ain’t your uncle Martin’s refactoring

I love the whole idea of Ambler and Sadalage's Database Refactoring book.  Like Martin Fowler, they provide a voluminous set of refactoring actions that you can apply to your database schema.  The whole technique of deprecating parts of schema for a progressive elimination of DB cruft is fascinating. One of the problems we face as database professionals is how to restructure our databases.  Any non-trivial encounter with this job will impress on you just how thorny it can be, even with a fairly simple-looking change.   But like many things, the fact that you can do something doesn't mean you should do it lightly.  When I joined Oracle, I was shocked that their conventions would prohibit (or severely restrict) dropping columns in tables.  A year later I realized how much easier it made my life. There is a whole rapid-iteration, prototype, full-steam-ahead practice of software engineering, embraced by many practitioners.  If it doesn't work, you throw it away.  Those who are used to it tend to think they should be able to do it with database design.  Unfortunately, you can't, or shouldn't. Why not? One reason is that it can take a while to determine whether your great data modeling idea was a success or a farce.  It can fall flat right out of the gate because of a simple oversight or lack of realistic test data.  For me, it's even more worrisome if it succeeds "beautifully" from the start.  Then you really have to worry about poor data!  But my point is that you can't just try it, toss it, try something else.  You have to get through a lot of validation before you know the answer. Another reason to defer or avoid refactoring is that in most cases you are destroying data.  Now let's be clear:  if you add a column, or relax a constraint, that isn't really 'refactoring' at all.  Add a table, revise a unique constraint, even altering nullity can destroy more data than it adds.  And again, you may not even know it until three weeks later.  This is about the time that the otherwise-cheery QA person comes shuddering to your desk, unable to fathom why fifty of her test cases stopped working.  You get your turn to blanch as you discover the answer is: you improved the database! So you should learn from Ambler and Sadalage, but be very, very careful about applying their techniques.  Don't use them too lightly.  Database schema refactoring is not like Martin Fowler's code refactoring.