On "A Call to Arms"

by C. J. Date

The subject article by Jim Gray and Mark Compton (ACM Queue 3, No. 3, April 2005) merits a response or detailed critique much longer than I have the time for right now.  However, its conclusions and recommendations seem to be based on—among other things—a few explicitly stated premises or assumptions that I certainly do want to respond to, and will.

"Traditional relational database constructs--always cumbersome at best--are now clearly at risk of collapsing altogether." 

    In my opinion, "traditional relational database constructs" are not now, nor ever were, "cumbersome at best."  Do the authors have a proposal for something to replace the relational model, something they can clearly show is less "cumbersome"?  If so, they need to tell us—in detail, please—just what it is and demonstrate just how it is superior to the relational model.  (Of course, if the authors mean that today's SQL implementations are cumbersome and in danger of imminent collapse, well, they might have a point; but if so, the point in question has nothing to do with "relational database constructs," and it isn't what they said.) 

"Classic relational database architectures are slowly sagging to their knees." 

    According to Fred Brooks, in his classic THE MYTHICAL MAN-MONTH, "the architecture of a system [is] the complete and detailed specification of the user interface."  For a relational database system the architecture is thus surely the relational model, which is very far from "sagging to its knees."  Now, if the authors want to argue that the user interface is not the relational model but, rather, the SQL language, then I might agree that it's sagging, but I would also argue that (a) SQL systems aren't relational and therefore that (b) the fact that SQL is sagging has nothing to do with "relational database architectures."  And if they want to argue that today's SQL implementations are sagging, well, again they might have a point; but if so, the point in question has nothing to do with "relational database architectures," and it isn't what they said. 

"Traditional relational databases [were] never ... designed to allow for the commingling of data and algorithms." 

    Relations are defined over domains.  Domains are types.  Values and variables of a given type can be operated upon solely by means of the operators defined in connection with that type.  The code that implements a given operator is, by definition, code that represents some algorithm.  Hence, data and algorithms are and always were "commingled."  QED. 

    PS:  The phrase "values and variables" in the previous paragraph is expressly intended to include relation values and variables in particular.  Thus, code, both user- and system-generated, that operates on relations certainly is or should be part of the overall database system. 

"Data and procedures are being joined at long last ... The problem starts, of course, with Cobol, with its data division and procedure division." 

    The errors in this extract are too extensive and too complicated to deal with adequately in a short note like this; suffice it to say that they have to do with (a) a lack of recognition of the purpose of a database, (b) a mistaken perception of how to achieve data independence, and (c), if the authors are to be taken at their word, the bizarre idea that, apparently, procedures can exist and operate without data. 

"Fields are objects (values or references); records are vectors of objects (fields); and tables are sequences of record objects.  Databases ... are transforming into collections of tables." 

    Attributes (fields?) are certainly not "objects" in the relational model.  Tuples (records?) are certainly not "vectors" in the relational model.  Relations (tables?) are certainly not "sequences" in the relational model.  And databases are certainly not "transforming" into "collections of tables" in the relational model.  Haven't the authors read Codd's papers? 

I've always held Jim Gray in the greatest respect, and I find it quite painful to see him attaching his name to a piece of writing as muddled as the subject article.  It's particularly distressing to see him signing on to, and thereby helping to perpetuate, some of the same old confusions that have plagued the database field ever since its inception.  Jim, please don't do it again!