Re: more algebra

compdb_at_hotmail.com wrote:
> On Apr 6, 5:05 pm, paul c <toledobythe..._at_oohay.ac> wrote:
> ...

>> But as we know, sql is not very rigourous [...]
>> So I think the simple user interface is a big trap.

Among other things, ignores or mangles empty sets, Date has written about that and other flaws. I thought the inconsistencies of SQL were widely accepted. Is it necessary to repeat the various autopsies? If it could be salvaged maybe, but I doubt if sql is salvageable.

> By the way it is important to have a keyword for keys.
> Although a non-keyword expression can be evaluated
> as a constraint there is in general no way to for a dbms
> to tell that a given constraint implies a key constraint.
> And it needs to know this for important optimizations
> (of other than just relational expressions).
>
> Although I sympathize with you I suggest that it is
> hopeless to choose the form of your specification on the basis
> of hoping to circumvent incompetent programming.
> COUNT has a precise & simple definition, why not use it?
> Yes, competent designers and implementers use math.
> Yes, most designers and implementers work willy-nilly.
> This is true for all programming.

As I said, I wanted to avoid COUNT even if I can't make it very clear why. Also cheated a bit by using D&D GROUP in example rather than trying to define an algebra that makes GROUP fundamental. But I wasn't motivated by 'incompetent programming', thought I did emphasize that the purpose was precise definitions for optimization.

I'll take a stab at a reason for avoiding COUNT even though I know it will probably seem murky. Off the top, it requires either a 'sweep' of tuples or a physical device that keeps a tally (I know D&D GROUP as defined currently also requires a sweep, please ignore that objection for now). Count or cardinality is an accepted property of a set and at some point in the development of a logical machine, people will want it (just as they will want keywords or some other convenient notation) but I want to postpone the introduction as long as possible. Maybe it's all prompted by my suspicion that Codd really should have made the values of his triples sets. From an optimization point of view, a 'mapping' from a key definition to the minimum 'access' performed by a logical machine seems more obvious when it involves only one tuple so I think this suggests confining attention to the possible forms a single tuple can take. D&D algebra builds up a lot of logical machinery before it gets around to grouping. It might be interesting or even useful to play the key card earlier on. If I am wrong about this, the exercise might still have value in showing that the COUNT approach is preferable. Received on Sun Apr 11 2010 - 16:26:34 CEST