Presentation: Refactoring Databases

Posted by Amr Elssamadisy on Mar 06, 2009

Sections

Process & Practices,

Architecture & Design,

Operations & Infrastructure

Topics

Architecture ,

Agile ,

Database Design ,

Configuration Management

Tags

Database Management ,

Database

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.

1. Back to top

   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.

   Reply

2. Back to top

   Re: Refactoring Databases

   by Jim Arnold

   John,
   
   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.

   Reply

3. Back to top

   Re: Refactoring Databases

   by Fadzlan Yahya

   John,
   
   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.

   Reply

• Older >