Edgar F. Codd: 1923-2003

I hope you will all permit a Devshed veteran to go slightly OT for a moment. Yes, the father of the relational data model has died. I can't imagine a better obituary than this one, which perhaps shows how instructive his life should be for we developers.

Wow, that is unfortunate. I am surprised I haven't seen anything on DBDebunk about it.

EDIT: nevermind, I see they did yesterday (I visited on Sunday ).

thanks, ry

for those who haven't seen it, the original paper (1970) is here: http://www.acm.org/classics/nov95/toc.html

anyone who worked with IBM's flagship database products IMS or DL/1 knows the type of institutional inertia he was up against


rudy

As a testament to IBM's will, we are using SQL today instead of Codd's mathematical language. I wonder how popular DBMS's would be today if they used Codd's language?

Sad news indeed. It's amazing how one man's intelligence, creativity and grasp of the truth can affect so many with or without their knowledge of his achievements.

Actually, as I was reading through several articles at dbdebunk I started thinking about something along these lines though. With the IT industry staying entrenched in its ways of what sells instead of what works best (in this case SQL/relation hybrid dbs vs TRDBMS) and tacking on the latest fads; what will happen to the movement (small as it may seem) of trying to get the industry to realize that many of the problems that they are trying to fix are due to not adhering completely to the relational model when the pioneers and main proponents eventually pass on?

Reading through dbdebunk (letters submitted from readers and the editors' replies) it's clear that even among those who want to understand how to do things correctly, many still don't necessarily grasp all the inherent qualities of the relational model (including myself). Even now, when the established authorities speak (Date, Pascal, etc.) on how things aren't the way the should be the industry simply dismisses them, even though much of what the industry has comes from their ideas. How much harder will it be when those who have the authority to speak on the topic can no longer do so?

-b

Of course, Slashdot rejected my submission for this story. I mean, really... who wants to hear about some dusty old database guy?

Why don't some of you other guys try submitting it. They can't ignore us all.

bcyde-

It's not all gloom, fortunately. There has been a revived interest in TRDBMS implementation in the past 3 or 4 years. And, you can see that there are even a couple open-source implementations underway: http://www.hughdarwen.freeola.com/T...b/Projects.html

As I posted at SitePointForums , I really wish I had the programming skill and resources to produce a true implementation of Codd & Date's vision. It's funny that (my current favorite) PostgreSQL at one time was based on Ingres, which used a language called Quel, which was apparently much more true to relational algebra than SQL. I wonder how hard it would be to fork PostgreSQL into an implementation of D, including all the cool possibilities with better DOMAIN implementation (user-defined datatypes and operators), type inheritance, nested set generation, full algebraic closure, arbitrary constraints, etc... IMHO, PostgreSQL is the closest thing to that vision currently available in SQL.

Yup, I've been lucky enough to find a job where they've been able to recognize Postgres' virtues and I really like working with it because of the DB itself, and because of its community.

When you say Postgres is the closest to the vision of a TRDBMS (of the ones based off of SQL), do you mean out of the open source DBs, or out of all DBs?

-b

Glad to hear it. Me too, fortunately.



I mean out of all SQL DB systems (commercial and otherwise), although I have to admit that there are some significant abilities in Oracle and DB2 that are very similar to PostgreSQL's, such as user-defined types and operators. (Actually, I think there's a fair chance that some PostgreSQL code has made it into DB2, Informix, and a few other systems )

But, as you can see from the previous link I gave, there is at least one commercial product, and a few open-source attempts at creating a non-SQL TRDBMS. Essentially, Date and Co. argue that SQL is too poorly designed to ever be the basis of a true relational system. I don't know if I completely agree, but it seems obvious that there is some sort of problem, if you realize that the current standards documentation for SQL-3 is over 1200 pages, and never ever once mentions the word 'relational'. Apparently this was a conscious decision on the part of the standards board. And why is the document so large? Could it be because of all the extras, feature-fluff, and work-arounds that had to be introduced to overcome SQL's short-sightedness?

Of course, none of the American L33t tech13 websites or even the normal IT mags cared to remind us who Ted Codd was, but at least The Register bothered to write about him more than once. A couple of interesting articles. Notice that the name Michael Stonebraker pops up, who helped create Ingres, which later became Postgres.

Read that other post on the Register that you linked to, rycamor, and it's interesting that they emphasize SQL's importance especially since Date and Pascal continually point out that SQL based DBs aren't truly relational.

And yes, it's sad that sites like /. don't recognize Codd's achievements although they slobber over anything John Carmack does. Don't get me wrong, I'm astounded by John Carmack's work both as a game player and because of the incredible way he's pushed graphics programming/technology, but it's a shame how quickly Codd's achievements are easily overlooked despite the enormous impact they've had on computing.

-b