« Subversion Gotcha #17 | Main | The Joy of Mighty Mouse »

Databases: A Necessary Evil?

Listen to this articleListen to this article

It's an attitude that I see all too often in developers, especially those that label themselves Object-Oriented Purists who are supposedly capable of precise, rational thought, above and beyond that which we might expect from your mere mortal developer.

Ever since my little rant on the subject over a year ago now I have been tempted time and time again to write something more but each time I go to put finger to keyboard I'm overwhelmed with a sense of resignation to the fact that when it comes to relational databases, most people just don't get it. If I only had a dollar for every time a developer has adamantly told me that foreign keys are a waste of time and that somehow primary keys are a neccessary evil to satisfy the requirements imposed by the database so that we can look up a record. "Why would I need all that nonsense?" they chortle rhetorically, "my application handles all that stuff just fine." Sure it does, so prove it!

What I find even more frustrating is the FUD spread by those I expect to know better. Case in point. I was doing some reading of old Ruby On Rails—yes, my shiny, not so new, toy—newsgroup postings when I came upon this from none other than Mr. Rails himself:

"And let it be no secret that I consider the database a necessary evil for the object-oriented domain model. Not the other way around. Hence, when given the choice between implementations that pit OO model against database purity, I will almost always side with the OO model."—David Heinemeier Hansson

Now the statement just quoted was apparently a justification for Single Table Ineritence and the absence of Mutliple Table Inheritence in rails. Fine. I have no issue with this at all. In fact one of the things I like about Rails is the fact that it is unashamedly "Opinionated Software": stuff works the way it does in Rails because, well, because that's the way someone decided it should. So why shy away from this with some spurious argument about what is/isn't good database design? Why not just admit that it's a personal preference and indeed that's the real reason it's like that? Would you consider Active Record a necessary evil or simply a design choice? I guess it depends who made the choice ;-)

So anyway, let's clear a few things up. Firstly, I'm fairly sure that when he (DHH) says database what he actually means to say is relational database—surely he doesn't mean Object-Oriented Database? Secondly, even though he means to say relational database, what he actually should be saying is SQL database—believe it or not there's a BIG difference!

Admittedly C. J. Date is not the most exciting read for many people but if you take the time to read some of his work on Relational Database theory, you might be compelled to re-consider your notion of the so-called "impedence mismatch" between Object-Oriented Design and Relational Databases:

"... As far as I'm concerned, an object/relational system done right would simply be a relational system done right, nothing more and nothing less."C. J. Date

I found it fascinating when I spent some time at a university many years ago that database theory was the least popular subject. Maybe it's just me? Maybe I really enjoy the subject because I see elegance and simplicity and yet enormous power in Relational Databases and it Just Made Sense™.

Relatonal Databases surely aren't as sexy as Ruby or Rails but neither are they glorified record management systems. They are very precise and provably correct repositories for our data. So, do what you will with databases, treat them as evil if you wish. but I think it behooves us to try and understand what we actually think we've supposedly moved beyond.

Update 18 January 2006: Primary Keyvil, Part I

Comments

The biggest problems I have with databases are:

1) They're on another machine. That makes talking to them slow. (cue arguments for in-memory databases)
2) 95% of the time, I've got nice object relationships that make things easy to walk, but which are mainful to load back in.

The right way to use a database, in my experience (which admittedly hasn't been that much): store objects in the database, but keep large caches in memory. Use SQL to find the ID of aggregate roots, then obtain the data you want by walking the (recently identified) aggregate root. In other words: use the database as a high power search enginge, returning keys back to your local cache.

Oooh, I love the term "Opinionated Software".

I couldn't agree more with this blog entry. I cringe everytime I hear about an "Object Oriented" extention to SQL. People have the wrong idea of what a relational database is. Not surprising given that SQL is NOT fully relational and no major database engines fully support Codd's 12 rules as intended (http://www.itworld.com/nl/db_mgr/05072001/). I learned a language called QUEL in college. I was later disappointed with SQL seeing how poorly it compared. IBM and Oracle screwed things up majorly when they pushed their early products. The Postgres people screwed up too when they dropped QUEL.

*sigh* ... Maybe someday there'll be a rediscovery of what was lost. It that were ever to happen, I think people would see how well OO and relational concepts can play together.

A silver lining: CA has Open Sourced Ingres which has QUEL support.
http://lwn.net/Articles/88128/

Post a comment