database
Improving with Age
Thursday, April 2nd, 2009 | | No Comments
When I design an application, one of the easier traps to fall into, is the idea that there is only one consumer of the database. This is the luxury of building a brand new web application that has no legacy integration requirements! But, it is a false promise, because it only lasts for a short period of time. Even if you never integrate with another application, the application itself becomes a “legacy” component. Eventually, there will develop a mismatch between the database and the application.
The database is something that needs to be refactored over time, just like the application. The job of a data service is to provide the view of the data that the application requires. If the applications requirements change, then so to should the database change.
With Ruby on Rails applications, I think developers are not strongly encouraged enough to think about the database this way. That almost certainly is a result of the creator’s opinion that a database is nothing more than a glorified hash map. The result is that a lot of the busy work of maintaining data is pushed into the application, increasing the cost of changing the schema. In particular you can look at the lack of support for database views. While they are treated as tables in the application, there is nothing that marks them as being views. That results in testing them being a little strange as you are forced to write fixtures for views when they should be calculated from other fixtures.
I hope I have time in the future to help improve that part of Rails, because I think working on those types of issues will bring about another round of “surplus” to the community. And this surplus will come for groups that might otherwise be tempted to scrap an application and start over, making the advantage even greater than the alternative.