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.