On "A Call to Arms"

by Hugh Darwen

[The following response was addressed to the editor of Database Debunkings, who rejected it on the grounds that it "elevates nonsense to a level it does not deserve", an observation that, although I might not altogether concur with it, I have no wish to dispute.]

I refer to "A Call to Arms" by Jim Gray and Mark Compton, in ACM Queue vol. 3, no. 3, April 2005, available at http://www.acmqueue.org.

I find this article rather puzzling.  It starts by making some pronouncements on things such as "traditional relational database constructs", "classic relational database architectures", and the like.  I find this terminology to be rather vague and in any case objectionable.  I'll first explain why and state what I assume them to be really referring to.  Then I'll explain why, under that assumption, I'm puzzled.

"Traditional relational database constructs"

Relational database isn't a tradition; it's a theory.  The authors claim, "... our traditional relational database constructs—always cumbersome at best—are now clearly at risk of collapsing altogether."  The constructs of relational database theory include, for example, the relation, the relational algebra, the domain (a.k.a. type), relation variables, and not much else, fundamentally.  Is any of these collapsing?  Of course not.  In that case, exactly what is it that the authors perceive as collapsing?

"Classic relational database architectures"

By "relational database architectures", I suspect that they mean the architectures, not of relational databases per se but of DBMSs that they take to be relational ones.  (Alas, the term "database" very commonly appears in place of "DBMS" in promotional literature; it is a shame to see distinguished authorities such as Jim Gray falling in with such practice.)  Unfortunately, even the term "architecture" is open to interpretation in this context.  However, I believe I am in good company by taking it to refer to the major components of a software system and how they fit together.  Such an architecture has the user interface at its top level and, if it is any good at all, has several other internal interfaces by which the entire implementation is divided into several discrete components.  Under this interpretation of "architecture", it soon became clear to me that the authors really mean the architectures, not of relational DBMSs in general but of SQL DBMSs in particular.  In that case we are witnessing yet again another very common and even more unfortunate confusion of terms: the confusion between "SQL" and "relational".  Even if SQL were relational (it isn't), it would be only one particular implementation of relational database theory.  Again one would hope that a distinguished authority such as Jim Gray would know better.  But I digress.

Now, I would expect each SQL implementation to have its own distinguishing architecture.  (Even the user interface tends to be a distinguishing feature, in spite of the existence of an international standard!)  However, I would not be surprised to hear that many implementations have very similar architectures, possibly not very good architectures.  Perhaps that is what is behind the authors' choice of the strange-looking term "classic" in this connection (do they mean "conventional"?).  Whether these classic architectures are perceived to be common to all SQL DBMSs is not clear.  Nor is it clear whether the perceived problems are really to do with the architecture(s) rather than with SQL itself.  If anybody were to ask me, I would say that I don't know much about the architectures but the language itself is certainly bursting at the seams and possibly sagging at the knees (as Gray and Compton put it) too.

Perhaps the sagging at the knees of the classic architectures and the risk of complete collapse of the traditional constructs are really just the same phenomenon, expressed in anthropomorphic hyperbole for sake of effect.  I shall assume that they really refer to the various encumbrances by which SQL has grown, like Topsy, over the past 25 years.  In that case, why does the marketing hype that constitutes the remainder of the article try to sell us all the very latest and in some cases most encumbering encumbrances, such as support for the XML data type, "objects", and Java?  And why doesn't it bemoan, for example, the extreme difficulty of adding temporal database support to SQL?  Some people, myself included, believe this difficulty to be a real and interesting consequence of the poor language design of SQL as well as its dubious antirelational constructs.

Another question: We are told, "A growing number of application developers believe XML and XQuery should be treated as our primary data structure and access pattern, respectively."  I was expecting this to be followed up by a rejection of SQL, and possibly a reasoned rejection of the relational model too (for XML and XQuery can hardly claim to conform to the relational model!).  But instead, as I have already observed, what we get is marketing hype for the very latest SQL enhancements (as some would call them).  Of course, my position would be to reject SQL in favour of a new language that is (a) well-designed and (b) truly relational.

Sincerely,

Hugh Darwen

hd@thethirdmanifesto.com