Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> comp.databases.theory -> Re: Idempotence and "Replication Insensitivity" are equivalent ?

Re: Idempotence and "Replication Insensitivity" are equivalent ?

From: <pamelafluente_at_libero.it>
Date: 22 Sep 2006 02:12:05 -0700
Message-ID: <1158916325.760757.265290@k70g2000cwa.googlegroups.com>

Chris Smith ha scritto:

> Second, how many times does it have to be explained that COUNT DISTINCT
> is best conceived as an aggregate function of a projection of a
> relation, and NOT directly as an aggregate of the relation? Why do you
> keep bringing this up? If you disagree, please provide a reason instead
> of just repeating yourself.

After I understood what a projection is (thanks :) ... )

... I think that the fact that with the projection device you reduce the countdistinc to a count does not really fix the basic issue here. (Further it seems that after projection you cannot compute other aggregate functions.)

I guess that the reason of requiring asssociativity and commutativity is because the underlying idea is that somehow an aggregate function is intended to be "order insensitive".

That is f(x1, ... , xn) remain constan over the space of permutations of x1, ..., xn

This was probably suggested because in general the record ordering may not be defined, or, better, may be defined "arbitrarily". So one would argue that it is useful to have functions whose values is constant whatever is the way the dbms "choose" to return the set of records of a query.

But the real world objection to this is that, sometimes, the user ORDERs the record and would like to compute aggregate functions that depends on such order. So does not really make sense to restrict to ass/comm functions.

For instance I may have a date field and may be interested to the first occurrence of a given event.

Also in actual reporting there are always comparers (a "comparer" is just
a function that given 2 objects can tell if they are different and which comes first in a custom order, formally a function returning -1,0,1 depending on o1 precedes, is equal or follows o2 ).

Since there are always comparers defined in any report (each field has its own comparer) the user very naturally uses any sort of aggregate
function that relies on that ordering).

-P

> Chris Smith
Received on Fri Sep 22 2006 - 04:12:05 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US