Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> comp.databases.theory -> Re: Extending my question. Was: The relational model and relational algebra - why did SQL become the industry standard?

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

From: Lauri Pietarinen <lauri.pietarinen_at_atbusiness.com>
Date: Mon, 10 Mar 2003 02:52:21 +0200
Message-ID: <3E6BE1C5.8000709@atbusiness.com>


Jan Hidders wrote:

>Lauri Pietarinen wrote:
>
>
>>I can't get into all the details here but there
>>there is lot's of discussion on different issues relating
>>aggregates in
>>Relational Database Writings 1994-1997
>>(ISBN 0-201-39814-1) installments 44, 45 and 50.
>>
>>
>
>I'm not much impressed by those references. The whole point of our
>discussion was to see how well their arguments stand up to critical
>examination. Since you apparently don't want to go into the specific issue
>that we were disussing I now get the feeling that you want to avoid that
>discussion.
>
>Pity.
>

I was not really trying to impress you by those references. I was just figuring that
since we were talking about aggregates we should have some reference (if not agreement)
as to what an aggregate function means.

And *if* we take the D&D interpretation then in my view bags do not bring any
optimisation enchancements over sets.

Regarding sets<-->bags in general I would sum up my arguments followingly:

  1. SQL operates in two modes: "bag"-mode and "set"-mode
  2. The user uses the "set" mode when he either
    • includes a candidate key in the result (implicit "set" mode)
    • or uses the keyword DISTINCT (explicit "set" mode)
  3. The user uses the "bag" mode when he does not include a candidate key in the result and does not specify DISTINCT (implicit "bag" mode)
  4. The user might mistakenly think he is in "set" mode because his test-query happens to return a result with no duplicates. However, in differenct circumstances (e.g. program in production) problems might arise because of dupcliates
  5. No user really wants duplicates in his result.
  6. Hence duplicates are actually a burden for the end user.
  7. They have also distracted DBMS-builders from the task of "dupcliate removal avoidance"

Regarding point 5) I challenge you to give me just *one* *real* *world* *example* in which duplicates would actually be of use to the end user.

It is not enough to say that

Exists X (X is an SQL-user (X wants duplicates in SQL-result))) => we just *have* to support duplicates, because, well, you know, it would just be so unpolite to support this one guy.

best regards,
Lauri Pietarinen Received on Sun Mar 09 2003 - 18:52:21 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US