InfoQ Homepage Presentations Refactoring Databases: Evolutionary Database Design
Refactoring Databases: Evolutionary Database Design
Summary
For years the norm for developers was to work in an iterative and incremental manner but for database developers to work in a more serial manner. The predominance of evolutionary development methods make it clear that the two groups need to work in the same manner to be productive as a team. Pramod presents material from "Refactoring Databases " on implementing evolutionary database development.
Bio
Pramod Sadalage is the co-author of the 2007 Jolt Productivity Award winning "Refactoring Databases: Evolutionary Database Development" and author of "Recipes for Continuous Database Integration". Pramod works as a DBA and developer at ThoughtWorks on large custom-developed applications which use agile. He has pioneered the practices and processes of agility in the database.
About the conference
QCon is a conference that is organized by the community, for the community.The result is a high quality conference experience where a tremendous amount of attention and investment has gone into having the best content on the most important topics presented by the leaders in our community. QCon is designed with the technical depth and enterprise focus of interest to technical team leads, architects, and project managers.
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.