The ORM Foundation

Andy Carver:

P.S. So I don't appear too biased for some people's tastes, I offer up an additional link, which at least gives both sides equal time -- in the persons of Messers Date and Codd:

Hi Andy,

Thanks for this. I will defer my response until I have read the 2010 book "Database Explorations" (by Chris Date and Hugh Darwen) which arrived by courier just one hour ago. 

Ken 

Hi Ken,

If it matters, I still think Clifford's terminology is less problematic: First, "purist" does not necessarily carry any negative connotation. I doubt that Mr. Date would object to the characterisation of himself as a relational purist; in fact, I think he'd happily agree with the characterisation.

   Second, the assumption that we agree on the meaning of "relational conformance" is guaranteed to lead to confusion, in a context where not even Ted Codd and Chris Date (and Hugh Darwen) can agree on what conforms to the (true) "relational model". So I fail to see the usefulness of that term at all, in the kind of disagreement we're in which guarantees we don't agree on the meaning of that term!

Cheers,

Andy

Just to say that I don't mind being called a relational purist.  After all, I can hardly deny it.  I claim, of course, that a "relationally pure" language, if well-designed by all other criteria of good language design, will be of more practical use than one that is impure (like SQL) and also well-designed by all other criteria of good language design (unlike SQL!).  Those who disagree with me will say, "The trouble with you is, your a relational purist and that's why I don't like your proposals".  So they attach some pejorative connotation to the term, but that doesn't make it ad hominem (unless of course it's meant to be taken that way).  It's relational purity they don't like.  I like it and my reasons for liking it are thoroughly practical as well as aesthetic. Some claim that NULL is thoroughly practical.  I disagree.  It's a judgment call.

Regards,

Hugh

Well said! Thanks, Mr. Darwen!

Dear Mr Darwen:

The only perjorative in my intent was against those who have come to think the SQL is a good example of the relational model! That is, I used the word "purist" to avoid confusion with the popular misunderstanding of "relational".

I bet you get very tired of being drawn into this kind of debate, with people who aren't equipped to understand your arguments. Nevertheless, that's not the case here, and I'd really like your comments on my previous discussion of the different requirements of conceptual vs physical layers, and the need for NULLs at the physical layer, hidden under a pure conceptual layer.

I'd also be delighted if you had time to comment on the conceptual difficulty (for ordinary mortals!) of expressing joins... I think SQL makes this stupidly difficult and have shown how it can be much easier in a more sensible query language. I think this is a mandatory requirement before we can expect people to normalise the NULLs out of their database design, whether or not we provide hidden conceptual->physical mapping intelligence.

In response to Clifford, in great haste because I'm about to be away and out of communication until next Tuesday:

(a) At the physical layer anything goes.  If some kind of "sparse matrix" gives desired performance while a more direct representation of the logical schema doesn't, then go for it.  (I have often made this point.)  But the things representing the gaps wouldn't be called NULL because that has semantics in the language (SQL) in which it is defined.  Nor would the storage and retrieval mechanism have to deal with 3-valued logic etc.

(b) Well, standard SQL has had NATURAL JOIN since 1992--what's more I was the one that put it there!  (It also has JOIN ... USING ..., which ought to be natural join with protection from inadvertently joining on the wrong attributes but alas it isn't, quite.)

In Business System 12 and Tutorial D, when you're confident that the attribute names are as you want them, you can write JOIN{r1, r2, ... rn} (though in BS12 the braces were parens) in place of r1 JOIN r2 JOIN ... JOIN rn.  (This thanks to JOIN's commutativity and associativity, of course.)

Regards,

Hugh