Re: does a table always need a PK?

From: Christopher Browne <cbbrowne_at_acm.org>
Date: 3 Sep 2003 04:19:32 GMT
Message-ID: <bj3q4j$eaohu$2_at_ID-125932.news.uni-berlin.de>


The world rejoiced as "Marshall Spight" <mspight_at_dnai.com> wrote:
> "Christopher Browne" <cbbrowne_at_acm.org> wrote in message news:bj30il$eoev7$3@ID-125932.news.uni-berlin.de...
>> "Marshall Spight" <mspight_at_dnai.com> wrote:
>> But it is /not/ obvious that the "+" operator represents a reduction
>> operator.
>
> Well, "obvious" is a highly subjective word, I suppose. My
> experience of the idea of sum() as being the same as reduce over '+'
> is that it is obvious.

I know what "reduce" means, as do you; I suspect that most people that use SQL haven't a clue.

And I would point to the difference between REDUCE and SUM (well, actually, "+") in Lisp as being relevant. In Common Lisp, there are two typical ways to sum up the contents of a list:

> (defvar mylist '(1 3 5 7 9))

MYLIST
> (apply #'+ mylist)

25
> (reduce #'+ mylist)

25

In the former case, + is being applied to the list as its argument. In effect, it is being treated as a "multi-adic" function, that can accept as many arguments as there are in the list. Reality is that Lisp functions are generally defined in such a way that they can only accept a limited number of arguments.

In the latter case, + is being used as a dyadic function to reduce the list. In effect, it gets expanded into:   (+ 1 (+ 3 (+ 5 (+ 7 9))))
which can accept a list of size that will only be restricted by memory size.

I don't see reason to consider it mandatory to apply reduction inside the SQL expression for much the same reason that Common Lisp doesn't assume that all expressions involve REDUCE.

>> select count(a + b) from table_t;
>>
>> The nature of the addition there is different from the nature of the
>> COUNT()ing. Perhaps "a + b" should be resolved by reduction of + over
>> a and b. But that's only "perhaps." If the thing inside the
>> aggregate was (a*a - b*b + 25), it is no longer obvious that it is
>> appropriate to recursively use reduction on the components.
>
> Again, the right answer here seems straightforward and obvious to
> me. Of course, I'm a 2VL guy, so maybe what you're referring to
> is more of the complications of 3VL. Or maybe I'm missing something
> completely.

I'm not assuming 2VL or 3VL here.

Merely that while reduction sure seems appropriate to apply to aggregates, it doesn't seem to forcibly have to apply to things that aren't aggregates. And (a*a-b*b+25) is not, in and of itself, an aggregate the way SUM() is.

-- 
"cbbrowne","_at_","ntlug.org"
http://www3.sympatico.ca/cbbrowne/sap.html
Rules of the Evil Overlord #1. "My Legions of Terror will have helmets
with   clear    plexiglass   visors,   not    face-concealing   ones."
<http://www.eviloverlord.com/>
Received on Wed Sep 03 2003 - 06:19:32 CEST

Original text of this message