On Tue, Jul 28, 2009 at 9:47 AM, Sam Mason <sam@xxxxxxxxxxxxx> wrote:
On Tue, Jul 28, 2009 at 09:14:38AM -0400, Robert James wrote:Not sure if I'd agree, a GROUP BY without any aggregate functions looks
> 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.
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 aI don't see why this is a problem at all; could you give a concrete
> 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...)
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.
