on 14 December 2007
I disagree with the first reviewer of this book. I think the reason for that is what he focused on.
"Refactoring" by Martin Fowler suffers from the same problem. The value in this book does not lie in the refactorings themselves. The value lies in the 100+ pages at the front of the book where the process and environment needed to refactor databases is described.
After having read these few chapters, a lot of people I have talked to are left with a feeling of having read a lot of ideas that should have been obvious from the word go. Yet, not a single one of them were able to come up with these ideas by themselves. That is where the real value of this book lies. This is not a blueprint book which teaches you how to go about refactoring database schemas. This book teaches how to remove the obstacles that make such refactorings impossible.
I think books which state the obvious ideas people don't seem able to dream up by themselves are the most valuable. Therefore I think this book warrants four stars.
on 13 June 2008
This is an excellent book! If you are from the Data world, please read this to see what can be done to make databases more flexible and resilent in the face of change. If you are a software developer, read and absorb the lessons, then leave this on your favourite DBA's desk for them to read too.
The book starts with a quick summary, useful if you only have a chance to skim this at first read. Then the authors describe how the patterns latter on in the book can and should be used. Another aspect I like is the way that typical objections are discussed and dealt with, as well as being realistic about potential problems. The rest of the book is made up of various patterns for database refactoring. There is good emphasis on the use of tests and testing to keep your data and application intact while you refactor.
You are going to get practical advice and guidance here which makes it worth the time to read this book. The writing style is easy to follow and gets to the point quickly and effectively.
Get this book, and absorb and apply the contents - you will never look at a data design, or a database in quite the same way again.
on 19 November 2012
This is not a book to be read from cover to cover. It is for the most part a reference book. I've been a DBA for 30 years and for the last 15 developed agile methods for continuous integration in multi-application single data model environments. Finding this book has confirmed some of the paradigms that experience has taught me. I would like to congratulate the authors for finding the time to document them. Personally I would have prefered more detail in the first part of the book. (It is stretching things a bit to say "the second half" since the split is roughly 20-80 bewteen describing databases in an agile environment and the refactoring patterns.) So in this respect I was a little disappointed.
The book could do with revising. For example the "Rename Table" refactoring covers only two options: "create table newname as select * from oldname" with database triggers to enforce data integrity between the tables; or "alter table oldname rename to newname" and an updateable view "create view oldname as select * from newname". Why not rename the table and create a synonym "create synonym oldname for newname"? Much simpler and works for Oracle, DB2, Sybase, SQL Server and PostgreSQL, but not mySQL unfortunately.
Overall I would recommend this book not only to DBAs, but to developers who will get an appreciation of the difficulties faced by DBAs in an agile world.