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

Date: 6 Mar 2003 10:14:40 -0800

Message-ID: <e9d83568.0303060823.3fcca129_at_posting.google.com>

*> >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