Manni Wood

Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.

– Philip Greenspun

So what about other data models?—the “object oriented model”, for example, or the “heirarchic model”, or the CODASYL “network model”, or the “semistructured model”? In my view, these other models are just not in the same ballpark [as the relational model]. Indeed, I seriously question whether they deserve to be called models at all.

– C. J. Date, SQL and Relational Theory, Appendix A, “The Relational Model”

Manni’s Prediction: Any sufficiently complicated data store will contain an ad-hoc, informally-specified, bug-ridden, (but perhaps fast) implementation of half of the relational data model.

I predict that, the same way Paul Graham’s “Revenge of the Nerds” says that newer programming languages are becoming successively more like Lisp as computers get more powerful, so too will the relational data model become more popular as computers get more powerful.

And yet, just today, I read another article discussing the imminent demise of the RDBMS.

On the one hand, I don’t think all data need to be stored relationally, as I’ve said before. Sometimes you just need an object store, or a document store, or just a plain text file. Not all data have to be relational data.

But when we look at data stores like Amazon’s SimpleDB, or Google’s BigTable, would those data stores provide relational features if they could do so without hampering response time and scalability?

I think that as computers become more powerful, many data stores that currently eschew relational features for performance reasons will start to adopt those features—much the same way Paul Graham points out programming languages are getting more and more like Lisp.

I’m reminded of a quote from a blog entry (“Social Media Kills the Database”) that keeps bearing creative fruit for me:

The internals are totally opaque for most [RDBMS] solutions. Optimization, required for any performant solutions, becomes a “black art”.

The exact same criticism has been (fairly?) leveled at Lisp.

And yet the opacity of the internals of RDBMSs (or Lisp) may end up being their greatest strengths. As C. J. Date puts it, the fact that the relational data model is not tied to any one implementation leaves lots of opportunity “to adopt creative approaches to questions of implementation.”

Or, as Paul Graham says about Lisp, “Lisp was a piece of theory that unexpectedly got turned into a programming language.”

So while Lisp itself may or may not take over the world, languages are becoming more and more Lisp-like, because the theory behind Lisp has proven to be too good to ignore.

And, I would make a similar argument for the relational data model. Perhaps particular RDBMSs are on their way out; maybe even SQL will one day go away; but only to be replaced by even cleaner, faster implementations of the relational data model. The relational data model is not just here to stay: it’s actually going to become more popular as it becomes technically feasible to use it in places where it currently has performance issues. It’s just a matter of time.