Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage Presentations Refactoring Databases: Evolutionary Database Design

Refactoring Databases: Evolutionary Database Design



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.


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.

Recorded at:

Mar 06, 2009

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.

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

Community comments

  • 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.


    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.


    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

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