Re: a union is always a join!

On 24 mrt, 02:36, paul c <toledobythe..._at_oohay.ac> wrote:
> com..._at_hotmail.com wrote:
> > On Mar 23, 11:09 am, rp..._at_pcwin518.campus.tue.nl (rpost) wrote:
> >>>> Yes, but what I meant to say is that in general, the tuples
> >>>> don't really express facts regarding those domain values,
> >>>> they just help express information about other domain values.
> >>> Tuples do not express facts about domain values. They contain domain
> >>> values.
> >> Duh.
>
> >> True, I didn't express myself clearly enough.
>
> >> But I don't need your lecturing.
>
> > Of course I know you know tuples contain domain values.
> > What you didn't seem to know is that they do not express
> > information about domain values, since you wrote the
> > opposite. I'm only being precise and basic to justify my
> > points clearly. I guess you think I'm too basic. But I think
> > that many things you write contradict basics, and that thus
> > basics are relevant to my reply.
>
> >> My point is that in a relational
> >> the tuples of a relation often correspond not just to the
> >> propositions of an associated predicate, but to observations; explicitly
> >> asserted, rather than derived information.  To propositional logic,
> >> it's all the same, of course.
>
> > Along the way you have said (along with a lot of other stuff
> > I contradict) that there is a distinction relevant to the user
> > between relations that observe changing things, those that
> > observe unchanging things and those that derive from
> > these; and that it is relevant to the user how any of these
> > are implemented. And I have said that there isn't. Other
> > than what the observing (changing and constant) relations
> > represent, to the *user* it's all the same. And treating them
> > them the same eases programming.
>
> > philip
>
> I just want to comment on one point, users can think whatever they
> want (when they away from the desk as it were), but when they are
> operating the db, the only view they should take is that of the
> intentions of the data design.  If the design doesn't concern itself
> with recording changes (as opposed to the result of recording
> changes), eg., if the design doesn't handle 'before' and 'after', then
> a user who concerns himself with that is a mystic!
>
> Obviously a data design is just a mechanical reflection of one or more
> chosen abstractions of reality.  All mystics should make a vow to
> remember daily whatMcCarthysaid about submarines trying to swim.

Oh dear. I'm afraid I only remember what E. W. Dijkstra said about submarines and swimming. ;-)

• Jan Hidders