The End of an Architectural Era?

Of course none of this is a new idea and none of it actually applies to a discussion on "relational" databases, since the Relational Model does not specify how the physical architecture should work.  On the contrary, it actually specifies that there -must- be a distinct separation between the logical and physical layers.  So were there actually a relational database that we could consider, it could easily support any number of back-end physical implementations.  Most SQL database vendors have managed to tightly couple the logical and physical implementations, but there has never been a reason that they had to do so.  So I really don't find this to be an end of anything, but rather more of a declaration of a correction of a path gone askew.

Add to that the fact that Chris Date's been saying for years that "SQL gets it wrong".  Look at his Tutorial-D language for his idea on how to do it "right".

Because the relational model is mathematical it continues to work regardless of the scenarios thrown at it.  That can't be said for the models being thrown about.

It is a good paper with much common sense about rewriting implenetations to take the best advantage of current and envisaged hardware and operating environments. Nothing controversial there.

He separates quite cleanly  the Relational Model from its implementation and also from its DDL, dealing in detail only with the implementation in this paper.

He makes a few vague hand waving comments towards the end about replacing the Relational Model with something else (no suggestions though) and hammers SQL without offering an alternative other than using non-declarative, non-set based languages like Ruby.

My view: I guess Stonebraker is about performance first approaches to data management. We need performance, but only in addition to data integrity.

Note the similarity of this paper to Jim Grays:

'A Call to Arms' ,April 2005

http://www.acmqueue.org/modules.php?name=Content&pa=showpage&pid=293

These papers all tell the same story. Sql is history because it can't adequately handle different 'types' of data. First, it took some thirty years for these geniuses to come to this conclusion? Second, the same old story - this is about sql and has nothing to do with the relational model. Stonebraker is an authority on sql (and quite the snake oil salesman). He is certainly not any kind of authority on the relational model. Nothing he is or was involved with even remotely demonstrated any understanding of relational.

>Look at his Tutorial-D language for his idea on how to do it "right".

Unfortunately TTM is far too abstract and too full of computer science for most sql folks to really understand. The design of the language, the synatax, is just a piece of the puzzle. I'm afraid the only way to get sql folks to see beyond sql and grasp a relational system with a D language is to sit them down in front of one. I only know of one such system and I haven't had a lot of success in getting sql cheeks in the chair :( :)

Interestingly, MS has used the same computer science to develop a new language (linq/esql) to go along with a different (object) model. Lets see how much success they have:)

Linchi Shea,

Again, you are talking about *implementation*--the physical layer--which is completely separate from the logical relational model.  Stonebraker's approach may be unique and novel, but it certainly is based on a very old and faulty view of the problem:  That SQL and current implementations of DBMS's are not capable of adapting to modern needs; ergo the relational model is wrong.

The Relational Model is a mathematical, logical model; it is most definitely not SQL, and it has not properly been applied to most current implementations of DBMS's.  This is something that Date has been clamoring for years--so in that regard, this argument is not new.  Instead of fixing that problem, the typical solution du jour seems to involve scrapping the robust mathematical model in favor of a more specialized approach which couples the physical and logical models more tightly.

   -dZ.