Twitter GitHub Facebook Instagram

Daniel Irvine on building software

Think carefully about your database design, because change is hard

30 July 2014

Databases represent the core of our applications. Programmers must make an effort to produce clean and correct database designs before building out application features. The architecture and design of the rest of the application will often be delicately constructed around the database design, so getting it wrong means expensive corrections later down the line, in more areas than just the database.

It’s easy to produce good designs for relational database systems. You simply follow the well-understood database normalization rules, and get your data into (at least) Schema migration works well for systems that support it, such as Ruby on Rails. This is the process of using tools to make incremental changes to database design, and fits well with iterative development processes such as XP and Scrum. But don’t be fooled: schema migration is no silver bullet. Making code changes after a schema change will still be hard, and you’ll be faced with code fear: fear that change will break your system.

This is yet another argument for test-driven development. The more you have specified your system, the more faith you’ll have when making changes in the inner core of your application, and the less likely you’ll be to screw things up.

About the author

Daniel Irvine is a software craftsman at 8th Light, based in London. These days he prefers to code in Clojure and Ruby, despite having been a C++ and C# developer for the majority of his career.

For a longer bio please see To contact Daniel, send a tweet to @d_ir or use the comments section below.

Twitter GitHub Facebook Instagram