On Databases

Last week David Heinemeier Hansson wrote a rather controversial piece about the use of stored procedures, triggers and relational constraints in databases. Later in the week Alex Bunardzic backed him up. What they both seem to be saying is that because we now have powerful tools to represent our data models in code[1] then there is no longer any requirement for the database to use any of these features which model parts of an application’s business logic. The argument seems to be that they want to model all of the business logic in the application code and that splitting it between the code and the database only complicates matters unnecessarily.

I just can’t agree with this point of view. If there are business rules which describe the valid states of your data then those rules belong in the database. The most obvious reason for this is that there will always be other applications that want to access the data in your database. These systems might not be built using the same tools as your original application and that makes it unlikely that they will be able to use your carefully constructed ActiveRecord code. Which means that someone else will need to reimplement the same business rules using their own favourite technology. And everytime the same logic gets reimplemented, there’s a chance that discrepancies will creep in. This is the Don’t Repeat Yourself principle in action.

The original articles recognise this problem and they think they have an answer. They talk about the difference between application databases and integration databases. They say that their rules only apply to “application databases”, which are database that only support a single application, as opposed to “integration databases” which are there to share data between multiple applications.

I think that this distinction is nonsense. In the real world, these “application databases” simply don’t exist. Or, rather, there are so of them that it’s not worth considering them separately. Oh sure, most databases start out supporting a single application. But once you start getting an interesing amount of data in it, there will be other applications that want to use it. And then they’ll want to start adding their data to your database. And before you know it your “single application” database is the company data warehouse.

Yes I’m exaggerating. But it happens. I’ve been building databases for almost twenty years and I don’t think I’ve every seen one that didn’t eventually become an “integration database”. And for a multi-application database you need to put as much as possible of the business logic into the database.

If the Ruby on Rails people are seeing a lot of single application databases then good luck to them. But I think it puts a serious question mark over their experiences with databases in the real world.

[1] They are tailking about the Ruby on Rails database access layer, ActiveRecord, but their points are just as applicable to things like Perl’s Class::DBI or Java’s HIberate.