Agile Databases

I am not an expert on this subject, although I play one on the Internet. Jason posted some thoughts about the relatively light use of the data tier in a recent TDD presentation he attended. Instead of writing the longest comment in the history of his blog I thought I'd post my response here. The following is a brain dump only, and subject to change as folks smarter than me correct me.

Martin Fowler has an article where he distinguishes between "application" databases and "integration" databases. To me this is the main difference between traditional "enterprise" thinking and the Agile approach. Most Agilistas (and the Ruby on Rails framework) like the "application" view, and every DBA I've ever known assumes the "integration" view. Here is what Martin Fowler has to say about the latter:

Integration databases end up with interfaces that have a large surface area and limited abilities to separate interface from implementation. The resulting links between applications and databases end up being brittle and thus difficult to change.

That perfectly describes my life.

I can't point to too many examples where I've actually reused stored procedures. Database functions yes, stored procedures no. I either end up writing new stored procedures for my new application, because the new application needs to access the data differently, or I hack up the stored procedures to do things they weren't originally designed for and effectively tightly couple my data and application tiers. In fact, my opinion is that the current irrational exuberance over SOA is mostly an acknowledgement of the fact that stored procedures make a shitty abstraction layer. But that's just my opinion, and unlike Erik Larsen I'm not that willing to concede I might be wrong. :)

Rails takes the view that you should have your complexity in one place, and code is a much nicer place than the database. That is one of the reasons Rails is called "opinionated software", because this world-view permeates the framework. Can you use Rails with an "integration" database? Sure, but it will be harder. And even though I have no idea exactly what SOA really, truly is, I'd investigate using SOA before strapping Rails on top of a legacy database where stored procedures are the only way to get or set data. So the "application" database approach is different, but its different for a reason.