From: Misha Dorman

To: Editor

Date: 6 May 2005

 

See A Call To Arms by Jim Gray and Mark Compton.

 

There is a hint of content there (column-stores vs. record-oriented physical layouts, publish-subscribe i.e. eager query execution, main-memory database approaches) but much is ignorant/misleading.

 

In particular:

 

A growing number of application developers believe XML and XQuery should be treated as our primary data structure and access pattern ... database systems will need to accommodate that perspective.

 

Mob rule rules, OK?

 

Even though all these ["object-relational"] approaches were fine in their own right ... each one in turn proved to be doomed by the same fundamental flaw [low take-up for new languages exacerbated by poor language design].

 

So the value vs. reference, OID,  table=class, data hiding vs. representation hiding, and procedural vs. declarative issues were not "fundamental flaws" then? I suppose, now that we can use Java/C#/whatever to write our stored procedures/triggers/objects-as-domains it will all work swimmingly? (Whereas a Tutorial D implementation would, by their argument, still be doomed because it would be "a new language"?)

 

Now [with SQLJ and other "object-relational" approaches] fields are objects (values or references); records are vectors of objects (fields); and tables are sequences of record objects. (my emphasis)

Increasingly ... tables ... incorporate thousands of columns ... many of the values in these tables prove to be null. (my emphasis)

 

No further comment needed, I think...

 

Databases [sic] offer vast attack surfaces [therefore] many designers [will] allow only Web servers in the DMZ.

 

So web servers like IIS have small attack surfaces, do they? (e.g. 39 SQL Server vulnerabilities vs. 83 for IIS since 2000, at www.securityfocus.com).

 

... not all data fits neatly into the relational model ... we all start with the schema <stuff /> and then figure out what structure and constraints to add.

 

 

(I assume by "the schema <stuff />" they mean a single table with a single column of type Object/BLOB)

 

And there was I thinking that finding the FDs and constraints was the whole point of schema design, not an afterthought.

 

My biggest complaint, though is that almost all the advances mentioned are physical implementation improvements to the DBMS (which are always welcome, of course, as long as we maintain logical-physical separation), but the article gives the impression that there is a (logical) sea-change coming which will sweep away RDBMS approaches (from the opening paragraph: "Under the mounting onslaught, our traditional relational database constructs -- always cumbersome at best -- are now clearly at risk of collapsing altogether"). Whereas, AFAICT, most of the improvements mentioned could be implemented within a SQL DBMS, and certainly don't mean that the relational model is in any way obsolete.

 

 

Fabian Pascal Responds: Looks like you know and understand database management better than the "distinguished" director of Microsoft's Silicon Valley Research Lab, and recipient of the industry’s most prestigious Turing Award (also received by Codd, who is probably turning in his grave). Unfortunately, you're in a very small (and diminishing) minority.

 

I have already opined on Gray’s pronouncements, and I’ve always said that things are getting much worse, not better.

 

A response by Lee Fesperman’s to A Call To Arms is forthcoming here. I have considered responses by Date and Darwen too mild for my taste—there comes a time where it’s necessary to call a spade a spade. Anything else risks, in an ignorant industry, to elevate nonsense to the level of material worthy of analysis, which it does not deserve (some have made careers seeking such elevations, see last two paragraphs of When “Fowl” Is All They’ve Got). So in my own response, A Call to Knowledge and Reason, forthcoming at dbazine.com, I do call the spade a spade.

 

 

Posted 7/8/05