Re: Idempotence and Projection
Date: Wed, 20 Sep 2006 13:54:26 GMT
Message-ID: <mKbQg.30682$9u.284843_at_ursa-nb00s0.nbnet.nb.ca>
David Cressey wrote:
> <pamelafluente_at_libero.it> wrote in message
> news:1158744368.333186.13750_at_k70g2000cwa.googlegroups.com...
>
>>David Cressey ha scritto: >> >> >>>If f(x) = SELECT * FROM x GROUP BY * >>> >>>then I would expect f(x) = x provided that x is a relational table. In >>>other words, I expect that projecting a relation into (or it it onto?)
>
> its
>
>>>own space is an idempotent operation. >>> >>>However, if x contains duplicate rows, >> >> >>Hi David, if you want to refer to my original problem, I must warn you >>you are not intending in my same sense sense. >> >>I never talked about "duplicate rows".
>
> You didn't talk about it, but you presented duplicate rows in your example.
>
>
>
>>The problem I am talking about is that in a chain of join you may have >>some values on some field replicated. This is * by the definition * of >>join. It's not an error.
>
>>In the relation 1-N things on side 1 gets "replicated" (say, >>duplicated) when you join.
>
> you can get the right number of rows in your query by projection.
Not always. If you don't want duplication from a join, don't do a join in the first place.
>>This can be however a problem in a report where you have "duplication >>sensitive" functions, for some (often pathological) design.
Well, duh. If a join isn't what you want, don't do a damned join.
> If the data design is pathological, it's sometimes better to copy the data
> to a database whose design is not pathological first.
It's not the design that's pathological--it's the person you answered.
> After that, getting the right result is merely a function of applying the
> correct relational operations. It's not hard to fashion your SQL so that it
> mimics relational calculus, provided you start with relational tables to
> begin with. If you apply SQL to bags and expect the result that relational
> calculus predicts for sets, you're going to get some nasty surprises.
[snip] Received on Wed Sep 20 2006 - 15:54:26 CEST