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.
Community comments
Refactoring Databases
by John Owens,
Re: Refactoring Databases
by Jim Arnold,
Re: Refactoring Databases
by Fadzlan Yahya,
Refactoring Databases
by John Owens,
Your message is awaiting moderation. Thank you for participating in the discussion.
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,
Your message is awaiting moderation. Thank you for participating in the discussion.
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.
Re: Refactoring Databases
by Fadzlan Yahya,
Your message is awaiting moderation. Thank you for participating in the discussion.
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.