Lambda the Ultimate

I did have a look at Dataphor a while back. One impressive feature was that it converted Tutorial D expressions as far as possible into SQL statements to be executed by the underlying DBMS product (which could be Oracle, SQL Server or whatever), thus taking advantages of whatever optimisations that product employed.

I understand Rel is built on top of Sleepycat's Berkeley DB, and is fairly unoptimised at the moment.

is that any column that has nulls should be moved into a child table (maybe a one-column table)

The null-rows become non-rows (they have no entry) in this new table.

Logically, if a NULL is 'missing information', then in this solution, it actually IS 'missing information'.

The result (AFAICT) was to make the logic of some statements a lot simpler - the usual 'is not null' clauses disappear (but the joins are more complex ...)

And that's why I don't take them seriously. Converting a table with N columns into N-1 tables with two columns is not my idea of progress.

It's as if someone proposed to get rid of the "clear" bit in GIFs, because after all, any non-rectangular image composed of pixels can be decomposed into a lot of little rectangular images, and image-processing code would be cleaner if we didn't have to special-case the clear bit...

(Then again, these days we use the alpha channel for image transparency. I wonder if there's an analogy for relational databases?)

"Converting a table with N columns into N-1 tables with two columns is not my idea of progress."

This is not the intent, nor the general outcome. The ideas are best explained in "The Third Manifesto" by Darwin and Date.

The issue is only that there is nothing in the relational model that prevents objects being stored in fields, not that they must be.

when was the last time GIF had pretensions of ensuring data integrity in a general purpose database system?

I'd love it if databases were easily programmed, speaking as one who's had his enough Pro*c coredumps for a lifetime. but why should a technology aimed at a completely different audience & purpose be changed to make my life easier?

Relational DBs were not meant for programmers. Ever.

was to present a relational language

and

do some kind of reconciliation between relational and OO databases.

It's been a while since I read it but they propose that OBJECTS should be mapped to COLUMNS, not to ROWS.

They claim that it is columns (data types) that have operations defined on them, not rows, and that's the logical mapping - defining operations on rows (what most "oo mappings" actually do) makes no sense in relational terms.

(this is from memory, correct me if I'm wrong) ...

I've forgotten what their suggestion was for replacing all the current code that defines "operations on rows" (AKA objects that pretend a row is the correct type to define operations upon).

actually just remembered as I write ... one suggestion was to put more emphasis on integrity rules so code can be moved out of objects and into the databaase.

I snagged a copy of their book "The Third Manifesto..." a while back. I was more interested in getting at the theoretical underpinnings of the "Relational Model", which the book attempts to explain, partially by answering the question of how to "extend" object-oriented ideas into databases.

The short answer to your question is, "Most definitely, a big yes."

They think that SQL, while allowing a programmer to try to conform to the relational model, does a lot to mess it up too, made worse by the typical implementations of SQL found in commerical systems. Tutorial D was their attempt at trying to fix that by not burdening themselves with compatibility with SQL.

Now, the thing is, while they are smart guys, and mathematical purity of the relational model are all to be appreciated, having studied programming language design myself(which is why I hang out here too much :) ), I think they are not sufficiently aware of the research in programming languages, and so while Tutorial D is faithful to their goals, seems a bit off at times(at least to me), especially since they talking about "typing systems", and it seems that there is a lot of work they are unaware of(I know because I am aware that I am unaware and trying to study it...).

As to other issues people bring up. They designed Tutorial D to be complete, so the issue of accessing a DB from another language is ignored. As to other goals people have like persistance of "objects" and/or serialization was not something they were concerned with either.

Perhaps the biggest issue that they feel DB's fail on is support of "updateable views", integrity constraint enforcement, support of user defined data types, and proper support of "keys". These are primary causes, whereas issues like NULL's, hierarchial databases, "too many tables/normalization is bad/joins are bad..." are the result of DB's not implementing these things properly, and that most programmers are not taught to understand the model.

Of course, I've wondered about design of a better language for DB stuff since I started messing with them, and their ideas have the ring of truth and the support of mathematics, its mostly lacking proper packaging in a programming language.

One of the more amusing sidenotes about trying to replace SQL are about performance/scalability in "commercial" db's. My experience is that most people wanting a DB, need it for like 10 people to hit it a dozen times a day. Now I realize there are _other_ situations out there, but I think making databases usable for "common people" in a theoretically appropriate way is the best way to empower users to write their own "code" to get work done. Of course, I'm not fond of the arrogance some of my peers have towards "common users", but that's a different issue for a different time...