Do I think SQL has a future? Yes, of course--of a kind. Here I'd like to quote something Hugh Darwen and I say in the Manifesto book:
We reject SQL as a long-term foundation for the future. However, we are not so naive as to think that SQL will ever disappear; rather, it is our hope that some D will be sufficiently superior to SQL that it will become the database language of choice, by a process of natural selection, and SQL will become "the database language of last resort." In fact, we see a parallel with the world of programming languages, where COBOL has never disappeared (and never will); but COBOL has become "the programming language of last resort" for developing applications, because preferable alternatives exist. We see SQL as a kind of database COBOL, and we would like some D to become a preferable alternative to it.
"Do I think SQL has a future? Yes, of course--of a kind."
Given that SQL databases and applications are going to be with us for a long time, however, we do have to pay some attention to the question of what to do about today's "SQL legacy" (I like this phrase). To this end, the Manifesto suggests that (a) SQL should be implementable in D--not because such implementation is desirable in itself, but so that a painless migration route might be available for current SQL users--and (b) existing SQL databases should be convertible to a form that D programs can operate on without error. And we've given enough thought to these objectives to believe they're achievable without compromising on any of the other goals we have for the language D.
Do I think SQL will be replaced by something closer to the relational model? Well, I think I've answered this question by now. Indeed, the hope of performing such a replacement is one of the major reasons we wrote the Manifesto in the first place.
Tony: So where is the future of database development?
Chris: Again I assume that by "database" here you really mean "DBMS" ... Some answers to this question are given in Database in Depth (pages 172-176); here I'll just briefly mention a few points.
- The first and overriding one is this: We need DBMSs that (unlike the mainstream products of today) truly and fully support the relational model. Again, that's what The Third Manifesto is all about.
- Second, there's a promising (and radically different) implementation technology called The TransRelationalTM Model coming down the road that looks as if it might be very well suited to that task of implementing the relational model properly. This possibility is under active investigation.
- Third, I'd like to see good support for temporal data. I think support for the time dimension is important already and due to become much more so. Now, several researchers have proposed approaches to this problem--approaches that are, however, fundamentally flawed for the most part (in my opinion), because they violate fundamental relational principles. By contrast, it's my belief that the relational model already includes what's needed to support the time dimension properly. All that's needed is a set of well chosen and carefully designed shorthands. Along with two coauthors, Hugh Darwen and Nikos Lorentzos, I've written about this topic at some length in another book, Temporal Data and the Relational Model (Morgan Kaufmann, 2003).
Perhaps I should say explicitly too that I don't think XML and XQuery are going to "take over the world" (despite all of the marketing hype to the contrary). People who think otherwise are simply displaying their lack of understanding of database fundamentals. As I mentioned earlier, I see XML (and the semistructured "model" on which it is allegedly based) as an attempt to reinvent the old failed hierarchic "model." This isn't to say that XML has no role to play--it probably does, but (to repeat) the role in question isn't that of taking over the world. XQuery in particular seems to me to be even worse than SQL! No, let me put a positive spin on that: If you like SQL, you're going to love XQuery. (Coming from me, you can take this remark as damning indeed.)
Tony: Finally, I have to ask: When Chris Date wants to build a database, what product does he turn to? Do you have time for consumer-level products such as Access? Do you think they have a place?
Chris: My lawyer has told me to say "No comment" to this one. Seriously, I do have a policy of never answering this question directly; I'm only too aware of what might happen if I were thought to be endorsing some specific product. (Did you expect anything different?) So all I can do is offer some platitudes: Even though they're all deeply flawed, you do have to use one of the existing DBMSs, because they're all that's out there--they're the only game in town, pretty much (though I'm being a little unfair here to at least one product, Dataphor from Alphora, which does constitute an attempt to implement the ideas of The Third Manifesto). Which particular product you choose will naturally depend on your own specific requirements (and yes, it might be one of the "consumer-level products such as Access"). But whichever one you do choose, you'll be able to make much better use of it if you're familiar with the underlying theory than you would be able to do otherwise ... which is one of the reasons why I wrote the O'Reilly book.
Tony Williams is currently a desktop support consultant at a major Australian university, specializing in Macintosh computers. He describes himself as a "professional Mac geek."
Return to the O'Reilly Network