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

Jan Hidders wrote:

>But you have been arguing all the time that we should keep things as simple
>as possible for the implementors. Have you now changed your mind?
>
The main claim was that if we use sets instead of bags there are more optimisations availabe
(e.g. as in the projection of view as mentioned earlier). SQL can be made to be "set like" when
we use DISTINCT and so we _enable_ the optimisations, in a sense.

However because the main focus in SQL has been on the bag-like features, lots of optimisation
avenues have been left untouched. They became distracted, in a sense.  Did it make life easier
for them? Maybe...

But wait! Why don't we just go back to DL/I and CODASYL? You know what?  We will make the
lives of implementors even easier: No optimisations are possible ergo no optimising problems!!!

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

>>>Meaning that in this case you might be right that for this particular query
>>>the bag-based approach makes optimization a bit harder. However, after
>>>giving it a bit more thought I doubt that even this is true. The problem is
>>>just as difficult in a set-only as in a bag-based approach. In both cases
>>>you can optimize a join followed by a project that projects out a certain
>>>table by using only the index for the "invisible" table.
>>>
>>>
>>>
>>Or ignoring it completely...
>>
>>
>
>That would be semantic query optimization and that is already hard in a
>set-only approach.
>
Is it easier in a bag-based approach?

>>Your point is that if the user gives the 'DISTINCT' keyword,
>>it works as if it was a set-based system.
>>
>>
>
>Yes, it should and it could.
>
In my opinion it is just an unnecessary distraction for both implementors and users.

regards,
Lauri Pietarinen Received on Tue Mar 04 2003 - 13:22:01 CET