Geeks With Blogs
Jeff Ferguson Irritating other people since 1967

I read, with interest, a post by Whitney Weaver about the “No SQL” movement. I have been, to this point, blissfully unaware of this movement. While I am not quite ready to get rid of SQL, I have been known to gripe about some of its applications and wanted to share my thoughts on the subject.

SQL (or, more correctly, a Relational Database Management System, or RDBMS) is fantastic at performing the work for which it was designed: the storage of related data. Through mechanisms such as referential integrity and triggers, the RDBMS platform has become a powerful engine for the storage of data. I remember my first internship in 1987, where I watched people run queries directly against an RDBMS and pull back just the data they needed. It truly was the right tool for the right job.

However, we have spent the last two decades (if not longer) building software systems on top of an RDBMS engine. From ODBC and JDBC to OLE DB to ADO to ADO.NET, we, as an industry, have invested a lot of time and effort into building software bridges to allow our object data (which can often be represented in a two-dimensional object graph, with parent objects holding references to children and collections of children) to be stuffed into an RDBMS. Has it been successful? Perhaps. In my opinion, though, it’s a fragile system overall, for a few reasons:

  • Dimensional Mismatch: As I noted above, RDBMSs are best at storing one dimensional data in a single row housed in a table. Our object graphs, however, can be two dimensional data representations, with cross-object references and related data. We have overcome this hurdle, for the most part, with careful management of primary and foreign keys, but, without continued care, this sort of system can become out of sync.
  • Separate Tools, Independent Management: I can design the best object model and data store in the world, but any such system comes down to independent system management by separate groups of people. The developers take care of their object model and the DBAs take care of the database. This works well, until one group decides to change something. Have you ever been on a project where a DBA decides to change the data type of a column, or a developer changes some data validation logic without informing the DBAs? Separate tools and separate maintenance teams offer one more place where something can go wrong. I once attended a class led by Brent Rector who said, “A thing built on top of a thing is not as good as a thing”. I have never forgotten that, and I think of it every time I see one architectural idea, such as classes, built on top of a separate tool, such as an RDBMS.
  • Not Data, But Data And Behavior: We very rarely pull data from a database and use it as is. Instead, we pull the data and run calculations or validations against the data. Where should this validation and calculation code live? If it is to live in stored procedures – which not all RDBMSs have – then the DBAs are in for a bit of a ride as all of the business logic is implemented in a set-based language like SQL. If, instead, the validation and calculation code is to live in business objects, then people who query the database without using the business objects miss out on the value-added business logic. Again, the “separate tool” idea comes back to bite us.

At this point, you can offer one big rebuttal to all of my whining: “OK, Jeff, then show me something better.” I can’t. For better or for worse, this is where we are today. But I am hopeful that things can change. If we, as a community, didn’t innovate, then we would all still be running Windows 3.1 on top of DOS. Perhaps “No SQL”, as a mantra, is a bit drastic; however, stretching the imagination and moving into new territory is not such a bad idea, either. Personally, I’d like to see a general purpose language carry more tightly integrated object state storage support rather than relying on a separate tool. Time will tell whether or not this will actually happen.

I find it interesting (but not ironic) that we are the industry who says “use the right tool for the right job”, and, in the next sentence, says “of course, everything has to be on the Web, the data format always has to be XML, and the data storage engine always has to be SQL”. I subscribe to the old adage that the answer to any design problem is “it depends”, which aligns much more closely with “use the right tool for the right job” than it does with “the data storage engine always has to be SQL”.

Posted on Monday, July 6, 2009 9:09 PM | Back to top

Comments on this post: RDBMS and The Right Tool for the Right Job

# re: RDBMS and The Right Tool for the Right Job
Requesting Gravatar...
well one nitpick... " RDBMSs are best at storing one dimensional data in a single row housed in a table"

Putting on a db oriented hat here... that goes against the fundamental idea of the "relationship" part of the rdbms. A well designed database schema with decent, multi part foreign keys is just as rich, imo, as a well designed object model. ("the key and nothing but the key so help me Codd

But...that just supports you second and third points even more, which I do agree with. The management of two systems and location of business logic. ORM frameworks attempt to alleviate some of the pain. And every once in a while a "pure" OODBMS comes around, but is rarely used. We seem stuck with these two worlds being mashed togehter... and I don't really see a way out. Nor do I think there has to be one, as you say, it depends on the job you want to get done.
Left by pcomeau on Jul 06, 2009 10:00 PM

Your comment:
 (will show your gravatar)

Copyright © Jeff Ferguson | Powered by: