On Tue, Jul 28, 2009 at 9:47 AM, Sam Mason <s...@samason.me.uk> wrote:
> On Tue, Jul 28, 2009 at 09:14:38AM -0400, Robert James wrote:
> > Many wrote that the functional programming 'fold' is a good model for
> > relational aggregate functions. I have a few difficulties with this:
> > 1. fold doesn't offer any type of GROUP BY, which is an essential
> component
> > of aggregation.
>
> Not sure if I'd agree, a GROUP BY without any aggregate functions looks
> pretty indistinguishable from just a DISTINCT on the same columns to me.
>
> DISTINCT will collapse duplicates, which is not what we want when computing
COUNT, SUM, or AVG - please see below.
> > 3. fold is defined on sequences, not sets. This doesn't seem to be a
> > problem until you think about cases where there a duplicates of the
> > aggregated field. (For instance, there are 10 bags each weighing 5 lbs,
> and
> > you want SUM(weight) - you need to project weight onto a collection which
> > allows for 10 occurences, or define the aggregate function to work on the
> > whole tuple somehow... I know a man named Krug worked out a formal theory
> > for this...)
>
> I don't see why this is a problem at all; could you give a concrete
> example?
>
Relation LUGGAGE = { (name:'ball', weight:3), (name:'bat', weight:3)}
How do we formalize SELECT SUM(weight) FROM LUGGAGE? We could
project_weight(LUGGAGE) and then apply SUM, except that would give us
{(weight:3), (weight:3)}, which is not a set (it has duplicates). We could
define a new operation: project_to_list (allowing duplicates), or we could
define SUM(weight) over the LUGGAGE relation as a whole - either way, we
need to extend the theory a bit.
