InfoQ

InfoQ

News

My Bookmarks

Login or Register to enable bookmarks for unlimited time.

The content has been bookmarked!

There was an error bookmarking this content! Please retry.

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.

  • This article is part of a featured topic series on Agile
Refactoring Databases by John Owens Posted
Re: Refactoring Databases by Jim Arnold Posted
Re: Refactoring Databases by Fadzlan Yahya Posted
  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.

  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.

  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.

Educational Content

New-age Transactional Systems - Not Your Grandpa's OLTP

John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.

Cool Code

Kevlin Henney examines code samples to see what can be learned from them starting from the premise that one won’t write great code unless he knows how to read it.

Collaboration: At the Extremities of Extreme

Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.

Yesod Web Framework

Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).

Transactions without Transactions

Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.

Attila Szegedi on JVM and GC Performance Tuning at Twitter

Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.

10 tips on how to prevent business value risk

One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.

Interview: Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives

InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.