Re: ID field as logical address

Bob Badour wrote:
...
> The only necessary data type is boolean. All other data types are
> superfluous. That doesn't reduce the utility of other data types.
> ...

I think it is possible to construct a 'toy' or 'educational' system that would demonstrate that it is not essential for a strictly minimal implementation to present any kind of boolean result, only producing relations, and supporting constraints as propositions, as long as projection on zero attributes is implemented. It depends on the beholder. Sure, I wouldn't argue that a system that supports relations with different headings isn't implicitly recognizing different relation types but exposing, say, the 'two-halves' of a comparison is not the same as exposing the result of the comparison. Maybe one day I'll finish trying to do that, thinking about it is one of my very few theoretical interests..

For example, just indulge me and take the common KEY ddl shorthand and express it algebraically. There are several 'constraining' relations that could result, depending on how the constraint is phrased. One might have only the non-offending tuples, one might have the offending tuples, one might simply produce a relation with no attributes. The first of those three constraining relations joined with the subject relation would produce a relation that satisfies the constraint. While extremely convenient for some languages to have a way of knowing the subject and the join were in fact the same relation, it is not absolutely essential to achieve a practical result. After all, if some tuples get 'dropped', it is only because they shouldn't have been present in the first place. In other words, it is not essential for an arbitrary constraint to result in 'true/false' or 'yes/no'. This is why I think the theory people usually talk about is over-enlarged compared to Codd's basic ideas, enlarged for admittedly reasonable and practical reasons but it's not always made clear that the reasons are practical and not entirely theoretical. So, at least for this case, I'd dispute that the boolean type is absolutely necessary. Unlike Date, I don't see Codd's model as being probably eternal, I'd have to see a lot more work done with constraints before that. (I know Date doesn't say exactly that, but he hints at it very confidently.)

One might say doing all that is silly, why should we when KEY's have already been 'solved'? If that's silly, then so is examining the nature of electrons. I think it's possible that some clues as to what a coherent optimization theory might require could result from that. Whereas I think it's very likely that every SQL implementation simply echoes the behaviour of the keys in file systems of the 1950's and 1960's.

While I'm on about this, Codd got a lot of flak for talking about 'time-varying' relations which is a mangled term. Then the OO language manglers turned the intransitive verb 'persist' into a transitive one, I think as a way to disguise the fact that they weren't quite sure what they meant. For purposes of a toy implementation, I don't have any problem pretending I live in a world where every operation materializes the result and makes up a name which can then be used to query the result. When you really get down to it, his theory is as spare as they come. Received on Fri May 29 2009 - 22:45:28 CEST