THE SQL Server Blog Spot on the Web

Welcome to - The SQL Server blog spot on the web Sign in | |
in Search

Linchi Shea

Checking out SQL Server via empirical data points

The End of an Architectural Era?

Alan Cranfield on the SSWUG list alerted me to a paper by Mike Stonebraker and folks, proclaiming the end of the current relational database architecture that is generally embraced by all the major commercial relational DBMS and annoucing that a far better paradigm would be based on specialized engines. You can find the paper here:

If anybody can make this type of bold prediction, Stonebraker certainly can, given that he is a pioneer and authority of the relational DBMS and such a fixture in the relational DBMS filed. That of course doesn't necessarily give him exclusive ownership to predicting the future. But whether or not you believe Mike Stonebraker has the crystal ball into the DBMS furture, the paper is an interesting read from a general DBMS architectural perspective.

To some extent, one can argue that DB2 v9 is moving in the direction of specialized engines when it has two separate engines, one relational and the other XML, in one system, albeit as a commercial system DB2 is nowhere near the radical proposal Stonebraker is advocating.

Now when it comes to this blog site, the Stonebraker paper is relevant to the discussions regarding 'beyond relational'. To some, this would be adding salt to the wound :-) For those who would like to continue that thread of discussions, take a look at

Published Wednesday, February 20, 2008 11:49 AM by Linchi Shea
Filed under:



Adam Machanic said:

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.

February 20, 2008 12:38 PM

AllenMWhite said:

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.

February 20, 2008 3:24 PM

Linchi Shea said:

Such a passion for the relational model :-)

February 20, 2008 5:19 PM

Slevdi said:

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.

February 21, 2008 3:42 AM

steve dassin said:

Note the similarity of this paper to Jim Grays:

'A Call to Arms' ,April 2005

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:)

February 22, 2008 5:57 AM

Linchi Shea said:

Far from being a strict relational model constructionist, I'm less concerned with whether we are exactly sticking to the founding father (Codd) 's original intent, but more interested in the practical utility of a database system.

One of things that a lot of people are working on is how to exploit the emerging multi-core/many-core technologies to build better systems. All sorts of things are being attempted and nobody has quite figured it out. So from one angle, this is an attempt in that regard.

Also, I disagree there is nothing new here. People are arguing that words don't matter. But this paper doesn't just argue. It discusses building a system, creating a prototype, and testing it out. That's action not just words :-)

February 22, 2008 10:10 AM

dz-jay said:

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.


November 14, 2008 6:00 AM
New Comments to this post are disabled

About Linchi Shea

Checking out SQL Server via empirical data points

This Blog


Privacy Statement