Presentation: Refactoring Databases

| by Amr Elssamadisy Follow 0 Followers on Mar 06, 2009. Estimated reading time: 1 minute |

For years the norm for object developers was to work in an evolutionary (iterative and incremental) manner but for database developers to work in a more serial manner. The predominance of evolutionary development methodologies such as Extreme Programming (XP), Feature Driven Development (FDD) make it clear that the two groups need to work in the same manner to be productive as a team.

Pramod Sadalage presents material from the 2007 Jolt Productivity Award winning book Refactoring Databases : Evolutionary Database Design on how to practice evolutionary database development and discusses the following techniques:

  • Database refactoring: Evolve an existing database schema a small bit at a time to improve the quality of its design without changing its semantics.
  • Evolutionary data modeling: Model the data aspects of a system iteratively and incrementally, just like all other aspects of a system, to ensure that the database schema evolves in step with the application code.
  • Database regression testing: Ensure that the database schema actually works.
  • Configuration management of database assets: Your data models, database tests, test data, and so on are important project artifacts which should be managed just like any other artifact.
  • Database Schema Deployment: Ensure that the scripts used to build development environments are the exact same used in QA, UAT and production. Ensure deployment to production is not a surprise and not a project in itself.

Pramod is an experienced database administrator and developer and has been working with Agile methodologies for ten years at ThoughtWorks.  His advice comes from years of experience.

Rate this Article

Adoption Stage

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Refactoring Databases by John Owens

The techniques employed in Refactoring Databases might well achieve all that is implied in this article. However, I think that the approach as outlined is flawed in that it suggests that changes to the corporate data structure can be determined from within a computer system.

A change is only required within a computer system when the existing system does not meet a business need or a business need changes or a new business need occurs.

So all such needs are driven from outside the system. If the overall data/information structure of the enterprise does not meet this new need then it must be amended. If that part of the structure supported by the computer system is amended then the system must be amended to make it support the structure.

So change is always driven by the information needs of the business. Systems must change to support the business. They are not the business, they do not drive change.

Re: Refactoring Databases by Jim Arnold


I don't see any conflict here; the users request a feature, the developers need to change the system in order to support the new feature. Refactoring is driven by change, and its goal is to reduce the cost of change.

Re: Refactoring Databases by Fadzlan Yahya


Did you watched the presentation? What the presenter proposing are methods to cope with changes that are driven by business needs.

I understand your concern if you are talking about refactoring per se, without any external events that triggers it, just for the sake of refactoring.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

3 Discuss