Book: Database Refactoring: Evolutionary Database Design

I had heard a lot of praise for Scott Ambler’s book: Database Refactoring: Evolutionary Database Design over the past few years. It’s another relatively classic book that I’ve been slow to read.

I often mentioned to people that when I was at a software design review meeting for Microsoft around the DataDude product (Visual Studio Team Edition for Database Professionals), I noticed that Sachin Rekhi from the team was walking around with a copy of this book under his arm. As Sachin was responsible for the refactorings to go into the product and there was only one (rename) at the time, I thought that was a good sign for where the product might head. I wasn’t aware that he had been a contributor to the book. Sachin wrote some of the opening details.

Now that I’ve read it, I’d have to say I was underwhelmed by it. I really liked the idea that someone would tackle this topic as it’s sorely needed in the database community where I endlessly see DBAs who feel like they can never change anything in their schemas. I spend a lot of time with DBAs discussing how they might “regain control” of their databases to avoid this.

The biggest problem I see with the book for a SQL Server DBA’s use is that Scott has (understandably) focussed on lowest-common-denominator approaches, mostly using triggers to achieve everything he does. The code samples are all from Oracle and I’m sure that wouldn’t help many although they wouldn’t be that hard to translate. But in the end, it’s often just the wrong approach. For example, he talks about how to introduce calculated columns as a refactoring, again using triggers to maintain them. But calculated columns have been part of SQL Server since 2000 and 2005 introduced persisted calculated columns. Each type of these is automatically maintained by SQL Server and each has a different use case.

That’s really the problem with the book. While the concepts are great, most of the book is filled with the “how and why” and the “how” is often far from what you’d want to do when working with SQL Server and the “why” is also often off the mark. Another example is his splitting of tables horizontally which would have been better done via table partitioning since SQL Server 2005.

So, in the end, I was left with very mixed feelings on the book. For DBAs who might not have been exposed to unit testing, test driven development, agile methodologies, etc. this might provide a reasonable introduction in a database context. But I wouldn’t want to see SQL Server DBAs following the advice on exactly what to do.

2008-06-07