Re: Bags versus sets; are they needed?

Anton Versteeg <Anton_Versteeg_at_nl.ibmdotcom> wrote in message news:<3CA9C01C.8701C7B5_at_nl.ibmdotcom>...
> Don't forget that you can select a subset of the columns in a table.
> So you can easily get duplicate resulsts when selecting not all columns.
> I agree with you that it doesn't seem very useful when a table contains
> duplicates when all columns are selected.
I agree with you that duplicates do not seem very useful when in a base-table.
My question is - and i will try to be more elaborate this time: is there any need for duplicates at all, specifically when when we talk about views or queries?
A query may of course contain duplicates in SQL, but what would result if we enforced a SELECT DISTINCT on all queries. Who would be unhappy? Is it the endusers, programmers or both? And more interestingly: why should anyone be unhappy at all?
>
> Usually a table has a unique primary index.
> That is the easiest way to avoid duplicates.
> I don't think allowing duplicate rows has anything to do with performance.
Why are they there then? I have heard convincing arguments AGAINST duplicates. What i am looking for now is a convincing argument (or more!) in favour of them.
>
> A similar difference between set theory and relational databases in
> practice is
> that sets don't have a sequence. It would be hard to tell end-users that
> they cannot
> rely on the sequence of the data that is presented to them. :)
Can they rely on that now? I do not believe so - unless you sort the result.

Kind regards
Peter Koch Larsen Received on Wed Apr 03 2002 - 14:58:26 CEST