An Interview with Chris Date
Pages: 1, 2, 3, 4, 5
Tony: The Third Manifesto introduced the relational language Tutorial D, and you use it for the examples in the new book. Do you think it has a future as an implementation or do you never intend it to be implemented?
Chris: Again I'd like to clarify a couple of things up front. First, I'd like to explain what The Third Manifesto is. It is a formal proposal by Hugh Darwen and myself for the future of data and data management systems. It's a fairly short document (maybe 12 pages); it's also pretty terse and, to be frank, not all that easy to understand. So Hugh and I wrote a book of some 500 pages (!) to explain it. The third edition of that book (Databases, Types, and the Relational Model: The Third Manifesto) is due to be published late this year or early next year. And the first confusion factor is that people often refer to that book, loosely, as The Third Manifesto--but it really isn't; in fact, the Manifesto proper constitutes just one chapter in the book.
Now in the Manifesto proper we--I mean Hugh Darwen and myself--use the name D generically to refer to any database language that conforms to the principles laid down in the Manifesto. Note that there could be any number of distinct languages that all qualify as a valid D. (Perhaps I should say explicitly in passing that SQL is not one of them!) And in the Manifesto book we introduce a particular D, which we call Tutorial D, that's meant to be used as (we hope) a self-explanatory basis for illustrating relational ideas--self-explanatory in the sense that if you're familiar with any conventional programming language, you should have no difficulty in following it. (I should mention in this connection that I've previously used Tutorial D in several other books, as well as in live seminars, and my experience does tend to confirm that it's sufficiently self-explanatory for the purpose.)
However, Tutorial D is, in a sense, only a "toy" language; it has no I/O and no exception-handling and is incomplete in various other ways as well. It follows that Tutorial D per se could never serve as a true industrial-strength language. But that doesn't mean we don't want to see it implemented! We believe it could serve as an extremely useful vehicle for teaching and reinforcing relational concepts before students have to get their heads bent out of shape from having to learn SQL. And as a matter of fact, some implementations do exist; you can find details (including downloadable code) at the website.
As you might expect, Hugh and I have a long list of follow-on projects to investigate when we get the time--and one of them is to take Tutorial D and extend it to become what you might call Industrial D. When it's defined, we would certainly like to see Industrial D (which by that time will probably be given some fancier name) to be implemented in commercial form. That's definitely one of our goals.
Tony: You say some fairly harsh things about SQL. What are the major flaws? Do you think SQL has a future or do you think it will be replaced by something closer to the relational model?
Chris: "You say some fairly harsh things about SQL": Well, you're not the first person to make this comment. One correspondent wrote: "As a practitioner, SQL is what I have to work with, and while I don't mind some criticism of its shortcomings, [your] criticism starts to look more like a personal vendetta." (Though the same correspondent did subsequently say it "finally made sense at the end of the book as to why [you] did this.") This is how I replied to these comments:
Oh dear. I tried hard to tone down my rude remarks; obviously I didn't succeed. I could have been much ruder, though! But the fact is that SQL fails in so many ways to support the relational model adequately--it suffers from so many sins of both omission and commission--that any book that both covers the relational model faithfully and discusses SQL as well cannot avoid being negative about SQL to some extent. It was interesting to me to discover (it wasn't explicitly intended on my part) how, almost always, the SQL formulation of any given problem was lengthier and more convoluted than its Tutorial D counterpart.
The same correspondent also felt that Tutorial D was a "distraction" and didn't "seem to help in illustrating relational concepts"--implying, I suppose, that if I wanted to use any language for the purpose I should have used SQL. Here I replied as follows:
This comment I do find surprising. I have to use some syntax to illustrate the concepts (even Ted Codd did this in his very first papers), and SQL manifestly doesn't do the job. Tutorial D not only does do the job but was expressly designed to do so! How would you illustrate the relational EXTEND or SUMMARIZE operators--or even projection--using only SQL, without getting involved in a number of distracting irrelevancies? And how would you illustrate the relational concepts that SQL doesn't support at all (e.g., no left-to-right ordering to attributes, relation-valued attributes, TABLE_DEE, etc.)? I could go on.
At the same time the correspondent also wanted me not to be so explicit regarding SQL's problems: "I think the book would be better served if [you] limited the discussion to just relational theory and let the reader (one enlightened) make [his or her] own judgments about SQL's inadequacies." Here I replied that I didn't agree, because:
- First, I think [the inclusion of SQL coding examples] is desirable to serve as a bridge between what the reader is supposed to know already (database practice) and what I'm trying to teach (relational theory). A book that covered the theory in a vacuum would be a different book--one that I explicitly suggested at the outset I didn't want to write, and one that would probably turn out to be (or at least look) too theoretical for my intended audience. (Incidentally, that different book would certainly have to use Tutorial D, or something equivalent, to illustrate the ideas--so this objection contradicts the previous one, in a sense.)
- Second, it's my experience that readers typically do need to have their hands held, as it were--points made only implicitly have a tendency to escape many people. (I don't mean this remark to be offensive! I include myself among those who often need their hands held in this kind of context.)
So yes, I do think SQL is pretty bad. But you explicitly ask what its major flaws are. Well, here are a few:
- Duplicate rows
- Nulls
- Left-to-right column ordering
- Unnamed columns and duplicate column names
- Failure to support "=" properly
- Pointers
- High redundancy
