Re: does a table always need a PK?

From: Marshall Spight <mspight_at_dnai.com>
Date: Tue, 02 Sep 2003 23:14:26 GMT
Message-ID: <mv95b.256868$It4.119666_at_rwcrnsc51.ops.asp.att.net>


"Christopher Browne" <cbbrowne_at_acm.org> wrote in message news:bj30il$eoev7$3_at_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.

> 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.

If you ask for the sum total of the expression "a*a-b*b+25" over a set/relation/table of tuples containing a numeric a and b attribute, then I don't see any need or value in anything other than the mathematical result. But again, maybe I'm missing something.

> > I am no fan of null, but even if we accept the idea of null, isn't
> > it possible to get whatever behavior we need by an appropriate use
> > of CASE or WHERE NOT NULL or some such?
>
> I'm sure it is possible; that still is quite ugly.

Sure it's ugly, but it's an ugly thing you'd be asking for. The right design choice is to make easy things easy and hard things hard; when you start making hard things easy at the expense of making easy things hard, you've gone down the wrong path.

Marshall Received on Wed Sep 03 2003 - 01:14:26 CEST

Original text of this message