Re: Extending my question. Was: The relational model and relational algebra - why did SQL become the industry standard?

> >The main claim was that if we use sets intead of bags there are more
> >optimisations availabe (e.g. as in the projection of view as mentioned
> >earlier).
>
> Which, taken literally, is nonsense, as I've already argued. At most you can
> claim that they make certain optimization harder to spot and then you still
> have to show *how much* harder they become.

I will get back to this one later...

> >>Could it not be that adding bags is also going to give us extra
> >>optimizations that would not be considered in a set-only approach?
> >
> >What would they be? Could you give me an example?
>
> Let's say I have a set X and I want to know the average of f(x) for all x in
> the set X. In the bag algebra this is straightforward: an iteration over X
> where you compute f(x), followed by the bag function AVG. If you simulate
> this with sets ( the bag {{x, x, y}} becomes {(x,2), (y,1)} ) then you get
> an iteration followed by a grouping on the values of f(x) and then you have
> to compute the average over the product of every element and its
> cardinality. It's not trivial to recognize that this is equivalent with the
> previous sequence of bag operations, which is often a more efficient
> implementation.

Could you clarify?

In "SQL-speak" what would this mean?

Something like this?

• "tuple bag" version SELECT AVG(F(x)) FROM X;

• "set" version SELECT AVG'( fx, count ) FROM ( SELECT F(x) as fx, count(*) as count FROM X GROUP BY x )

??

regards,
Lauri Pietarinen Received on Thu Mar 06 2003 - 19:14:40 CET