Industrial Deals Prime Book Box Men's Summer Sneakers nav_sap_plcc_ascpsc The Internet New Moto G6 64 GB | $299.99. Save with Prime Exclusive Phones. Starting at $39.99 Grocery Handmade Personalized Jewelry modern furniture and decor Book a house cleaner for 2 or more hours on Amazon outcastS4 outcastS4 outcastS4  Echo All-new Show Mode Charging Dock Kindle Paperwhite GNO Shop now SWMTVT18_gno



on August 16, 2008
In software development a 'refactoring' is a change that improves code quality without changing functionality. Refactoring helps keep an application maintainable over its life-cycle as requirements evolve, and is particularly of interest to those adopting modern 'agile' methodologies. This book comprises five general chapters on database refactoring - about 70 pages - followed by a 200 page catalog of various refactorings. The refactorings are classified as 'structural', 'data quality', 'referential integrity', 'architectural' and 'methods'. An additional chapter catalogs 'transformations', more on which in a moment. Each catalog entry uses a template including 'Motivation', 'Tradeoffs', 'Schema Update Mechanics', 'Data-Migration Mechanics' and 'Access Program Update Mechanics'. The 'Mechanics' sections include example code fragments for Oracle, JDBC and Hibernate.

Several of the structural refactorings are just simple database schema changes: rename/drop column/table/view. Adding is not really a refactoring so add column/table/view were cataloged as 'transformations' - changes that do affect the application, a distinction that appears to me a little clumsy. Some structural refactorings are more interesting: merge/split columns/tables, move column, introduce/remove surrogate key, introduce calculated column, introduce associative table.

The data quality refactorings include introduce/drop default values, null or check constraints, standardize codes, formats and data types, use consistent keys and lookup tables. Most of these are common best practices, seeing them cataloged as refactorings didn't yield me any new insights. Only replacing type codes with flags was of special interest.

Referential integrity refactorings include the obvious add/drop foreign keys with optional cascading delete, but also using triggers to create a change history and hard vs. soft deletes. Using before and after delete triggers to implement soft deletes is probably the best example in the book.

Architectural refactorings include using CRUD methods (ie. stored procedures or functions to select/insert/update/delete records), query functions that return cursor refs, interchanging methods and views, implementing methods in stored procedures, using materialized views and using local mirror tables vs. remote 'official' data sources. All these are common design techniques and the discussion of motivation and tradeoffs is particularly relevant.

The final section on method refactorings is more abbreviated and covers typical code refactorings. These qualify for inclusion only because databases include stored procedures, but they have nothing to do with schema evolution.

An important aspect of this book is that the catalog of refactorings is presented in the context of evolutionary database development described in the first five chapters: this approach emphasises an iterative approach, automated regression testing, configuration control of schema objects and easy availability of personalized application database environments for developers. Refactorings and transformations are intended to be applied one by one, and an automated regression test suite used to maintain confidence that a change does not introduce an application defect. Change control and a change tracking mechanism are essential to manage the application of schema changes to integration, QA and production environments.

What do I like about this book? The catalog of refactorings is thorough (some might say pedantic) which makes it a good learning tool for new database developers and DBAs, and as a shared reference for communicating on larger projects and in larger organizations. Experienced DBAs working on smaller projects are less likely to find it useful.

What don't I like? Relatively little is provided about the tools required to make regular refactoring practical, the authors simply state that these are being worked on. utPLSQL is not mentioned at all. The discussion on tracking changes is thin (but check out the LiquiBase project on Sourceforge). No guidance is provided on how you might use Ant to build and maintain developer database environments. Little is covered on the tough topic of building and maintaining test data sets. A final pet peeve: no discussion of refactoring across multiple schemas shared by an application suite.

In summary this book sketches out some important ideas but much work remains to be done. The catalog takes a number of established techniques and best practices and places them in a new framework which at least provides value to some for now.
18 people found this helpful
|0Comment|Report abuse
on August 12, 2008
As I had never thought about data model maintenance in terms of "Refactoring", the title of this book was very appealing to me. Creating a data model from scratch on a development environment is a relatively easy thing to manage; updating an existing one on a production environment with a lot of dependencies, is certainly not.

Like accomplished taxonomists, Scott Ambler and Pramod Sadalage elaborated an exhaustive catalog where they identified, named, and classified most (if not all) of the transformations that can be applied, not only to the database itself (e.g. Drop Column, Rename View, Split Table) but also to the data (e.g. Apply Standard Codes, Introduce Default Value, Introduce Common Format) and to the methods (e.g. Add Parameter, Rename Method, Remove Middle Man).

Each transformation is clearly explained together with a suggested strategy for rolling-it out into production. References on the inside cover serve as an index to easily locate each particular refactoring and transformation.

This book should certainly be on the bookshelf of any person responsible for maintaining a database.
|0Comment|Report abuse
on October 9, 2014
Interesting look at how can make evolve your database with changes over time. However the techniques and patterns seem to be suites for large organizations that can schedule changes across years and manage future work
|0Comment|Report abuse
on July 1, 2018
So, more like a FAQ that could be posted online.
|0Comment|Report abuse
on January 2, 2015
There are so few good books out there on database design, and even fewer on improving the design of existing databases. Loved the format of this book and the thought that went into it. Original thought-provoking ideas. I work as a database designer, and I love this book. I've used it several times when I need to back up an argument with management, and it's worked like a charm.
One person found this helpful
|0Comment|Report abuse
on September 24, 2017
This book is pretty remedial for someone who has been immersed in Agile development.
|0Comment|Report abuse
on February 2, 2014
My son had requested this book for Christmas. It was HIS pick so figured it must be a good book for what he wanted it for. Didn't hear any complaints.
One person found this helpful
|0Comment|Report abuse
on May 25, 2007
Scott Ambler and Pramod Sadalage wrote Refactoring Databases, they say, "to share their experiences and techniques at evolving database schemas via refactoring". The book, particularly in the thorough list of refactorings detailed in later chapters, reveals them to be experienced users of, and writers about, agile development approaches. Their core premise is that data and databases must evolve in the same way as code does - that is incrementally.

They argue persuasively that a big-bang, up-front approach to database design is unacceptable in a modern environment. There is simply too much change and too much uncertainty in the business world for this to be realistic. The basic techniques for evolutionary database design include refactoring (the topic of the book), evolving the data model, database regression testing and configuration management and developer sandboxes. This more evolutionary approach is going to be a big shock for many data professionals, something the authors note, but I think the need for effective evolution and ongoing development of applications and thus their databases is compelling. "Change time", the period after an application (or database) is first deployed is bar far the majority of the life of an application. Techniques that help you cope with this, like database refactoring, are a good thing. Database refactoring as described in the book, is part of an evolutionary approach and with development teams taking on SCRUM, XP and other agile methods it is more important than ever for database teams to do likewise. Many data professionals will likely have the same knee-jerk reaction I did when first approaching this - Why not just get it right up front? But if you believe that agile model-driven development is here to stay for code then you have to accept the need for the same approach to database design.

Martin Fowler's original book Refactoring: Improving the Design of Existing Code made the point that a refactoring must retain the behavioral semantics of the code and this is just as true in databases. The authors take great pains to explain refactoring in enough detail that it you can apply it constantly to keep the database as clean and easy to modify as possible. They emphasize repeatedly the value of test-driven or test first development - even in database design and deployment. The authors stress the importance of testing, especially regression testing, of all the components that access a database when refactoring it. They advise making refactoring efforts small as well as test-driven. They point out that refactoring should be done as a series of small steps and that database develops must not succumb to the temptation to combine refactorings into larger, more complex efforts. The need to treat database designs, and even data, as artifacts subject to change control comes through loud and clear.

The concept of a potentially very long transition period in which both the old and new schemas are supported is a particularly good one. I worry about the organizational dynamics of having the old schema removed by a new team that does not remember the original refactoring but nothing else seems rational in a typical environment where many applications run against the same database. I also liked the paranoia of the authors, for instance in their suggestion to always run regression tests BEFORE refactoring to make sure the database is actually as you think it is! While the book focused on refactoring, many of the hints and suggestions would be good for implementing real changes in business policy.

The book is a surprisingly easy read for such a potentially dense subject. The book starts by describing the fundamentals of evolutionary database development and the basics of refactoring. A process overview, deployment notes and some best practices follow. These initial chapters, designed to be read in sequence, introduce and explain the topic well and have a nice little "What you have learned section" at the end. There were many worthwhile asides in the book as it covers these topics and after these introductory chapters, the book then goes (somewhat abruptly) into a series of chapters on various kinds of refactoring - structural, data quality, referential integrity, architectural, method and transformations. These chapters take a series of very specific refactorings. The potential motivation, tradeoffs and implementation mechanics are defined for each. The refactorings are self-contained and, while this makes reading them as a set somewhat repetitive, it should make the book a much better reference guide for actual users.

The book did not really touch on how you should consider data and database designs used in analytic models or the potential value of using business rules, but these are minor quibbles. The book is well written, full of great examples and gives lots of good advice.
3 people found this helpful
|0Comment|Report abuse
on June 12, 2008
The bulk of this book is a catalog of database "refactorings" such as "rename table" or "add column constraint". Each refactoring includes a brief description and the steps you'd go through. There is often also some stored procedure code, with the odd JDBC code or Hibernate configuration fragment. This is all interesting, but a bit tedious to read through from A to Z, so it's best used as a checklist when doing a change (though it's usually nothing surprising).

The more interesting part of the book talks about how to manage and evolve a database in general (e.g. keep a table that tracks all changes that have been applied). But this part doesn't go quite as far as I'd hoped it would, e.g. there is no discussion of how to track down who is using what parts of the database prior to refactoring (proxy driver? access stats?), and the discussion is limited to relational databases (which may not even be the best choice for rapidly evolving data models).

btw there is an interesting open source tool called LiquiBase (apparently inspired by this book) that attempts to help manage (and deploy) database "refactorings" as described in this book.
7 people found this helpful
|0Comment|Report abuse
on November 15, 2015
Eric Jain's review rings true to me. There are no complaints - this is a high-quality book - but also there is no feeling that "Refactoring Databases" is a reference that I need to keep.
One person found this helpful
|0Comment|Report abuse