Re: does a table always need a PK?

From: Bob Badour <bbadour_at_golden.net>
Date: Tue, 2 Sep 2003 21:51:35 -0400
Message-ID: <H_c5b.410$XS2.42667041_at_mantis.golden.net>


"Lee Fesperman" <firstsql_at_ix.netcom.com> wrote in message news:3F553E89.5AD9_at_ix.netcom.com...
> Mikito Harakiri wrote:
> >
> > "Christopher Browne" <cbbrowne_at_acm.org> wrote in message
> > news:bj30il$eoev7$3_at_ID-125932.news.uni-berlin.de..
> > > Consider:
> > >
> > > 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.
> >
> > Since we can express count via sum, where
> >
> > select count(a + b) from table_t;
> >
> > becomes
> >
> > select sum(1) from table_t;
> >
> > could I suggest that "count" is redundant operator, so that we can drop
it
> > from consideration altogether?

>
> You might replace count(*) with sum(1), but count(a + b) only counts
tuples where (a+b)
> is not NULL.

Actually, SQL will not allow one to replace count(*) with sum(1) because count(*) gives 0 for an empty table while sum(1) gives NULL. Of course, the corresponding expression for count(a+b) is sum(case a+b when null 1 else 0 end case) or sum(isknown(a+b)) or some such. Received on Wed Sep 03 2003 - 03:51:35 CEST

Original text of this message