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

>
>
> SET(SET(A) INTERSECT(SET(B UNION C))) =
> SET(SET((A) INTERSECT SET(B)) UNION (SET(A) INTERSECT SET(C)))
>
>So, although things get a bit more complicated, there is absolutely no
>reason why a query optimizer that is based on a bag algebra would
>perform worse than one that is based on a set algebra.
>

So the point here seems to be that in SQL we can always use 'DISTINCT' anyway and the optimizer will be able to take that into account and optimize accordingly?

e.g.

select distinct s.s#
  from s, sp
  where s.s# = sp.s#

could be converted into

select s.s#
  from s
  where exists

     ( select *
          from sp
           where s.s# = sp.s# ) ?

In principle this is correct, but:

• more work for the optimizer groops because it has to support two "modes"; hence bigger and buggier products.
• optimizing efforts will be concentrated on the most used features, that being queries without disticnt.

I would draw a parallel with using GOTO's in programming languages:

• GOTO's give programmers more freedom to do what they want
• however, the programs are harder to optimize, so programs will end up being bigger and running slower
• compilers will be harder to write
• the programs will be probably be buggier
• and as Dijkstra has pointed out, everything can be done _without_ GOTO's anyway.

By point here being that by providing users with both tuple bags and relations (by use of distinct) we are actually causing more confusion for all!

regards,
Lauri Pietarinen Received on Sat Feb 15 2003 - 12:19:00 CET