Bob Badour wrote:
>"Jan Hidders" <jan.hidders_at_REMOVE.THIS.ua.ac.be> wrote in message>news:3e620dec.0_at_news.ruca.ua.ac.be...>>>> Lauri Pietarinen wrote:>> >>> >>>So actually your views are quite close to Date's, it seems! What you>> >>>are describing sounds like Tutorial-D, to me. Does "SQL with set>> >>>semantics" mean what I think it means?>> >>>> >>Yes, it does.>> >>>> >Maybe I am missing something here, but what is it _exactly_ you are>> >criticizing Date of? Is it the issue of equating SQL with bag algebra?>>>> Yes, that too, but mainly that he overestimates the complexity that is>> added to the optimizer when bags are exposed to the user.>>The optimizer may not be any more complex, but it is nowhere near as>effective either.

No. It can be just as efective.

>> >>>The query>> >>>>> >>>SELECT CITY>> >>> FROM P>> >>>>> >>>answers the question>> >>>"what cities do parts come from?">> >>>> >>Yes, it does, but under SQL semantics it also contains the information>> >>how many parts come from each city.>> >>>> >In a sence, yes, but then you have to have a program to tidy up the>> >result or count the duplicates. Why would you want to do that in a>> >program?>>>> If that is what the user asked then that is what he or she will get. If>> they wanted something else, they would have asked a different query.>>Are you not now requiring that all users have expert level knowledge of the>dbms internals?

No.

>When I look at your statement above, I think: "Well that totally>invalidates the argument that duplicate removal costs too much in>performance."

Why do you think that?

>> >Well, it was not used because users were advised against using it:>> >"Don't use 'DISTINCT', it will result in a sort!". So it was kind of a>> >vicious circle.>>>> That's nonsense. DISTINCT is usually not used because you don't need to,>> because for example the SELECT clause contains a candidate key. It is>> very rare in my experience that users deliberately accept duplicates.>>Jan, with all due respect, I cannot count how many times I have heard>alleged database experts tell users to "Never use DISTINCT." If the result>is already distinct, the keyword should have no cost.

Yes. *should* is the right word. Deriving that "at compile time" is not a
trival problem.

>> What makes you think that while-loops raise the level of abstraction?>>What makes you think they don't?

They are both imperative programming constructs.

>> >Let's say for sake of argument that P has 1 row, and SP has 1000000 rows.>>>> That assumption makes the example extremely unrealistic because if that>> were the case it is very unlikely that the user would accept that many>> duplicates in the answer.>>Why should they accept any duplicates?