THE SQL Server Blog Spot on the Web

Welcome to SQLblog.com - The SQL Server blog spot on the web Sign in | |
in Search

The Bit Bucket (Greg Low): IDisposable

Ramblings of Greg Low (SQL Server MVP, MCM and Microsoft RD) - SQL Down Under

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.

Published Saturday, June 07, 2008 6:35 PM by Greg Low

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

 

Aaron Fischer said:

I wasn't very impressed with the book either.  It always seems that books that swerve towards how tos, lack any usefulness after their publish date.

June 7, 2008 11:20 AM
 

John Paul Cook said:

As I've blogged previously, I prefer intelligent design of databases over evolution.  :-)

June 8, 2008 5:09 AM
 

Stephen Morris said:

I'm pleased I'm not alone, I borrowed this book from a colleague & came away distinctly unimpressed. Largely because of the idea of implementing most things through triggers & the consequent impact upon performance.

I thought Gert's post on the topic was much closer to the target.

http://blogs.msdn.com/gertd/archive/2007/07/11/table-structure-changes.aspx

June 9, 2008 4:21 AM

Leave a Comment

(required) 
(required) 
Submit

This Blog

Syndication

Tags

No tags have been created or used yet.
Powered by Community Server (Commercial Edition), by Telligent Systems
  Privacy Statement