"Bob Badour" <bbadour_at_golden.net> skrev i en meddelelse
news:7occa.17$zx3.2161727_at_mantis.golden.net...
> "Mikito Harakiri" <mikharakiri_at_ywho.com> wrote in message
> news:Y58ca.24$wV5.164_at_news.oracle.com...
> > "Bob Badour" <bbadour_at_golden.net> wrote in message
> > news:NY7ca.4$GY2.112751_at_mantis.golden.net...
> > > > In SQL there is a "select" clause, it corresponds to projection
> > operation
> > >
> > > Actually, it is a combination of extend, project and summarize.
> >
> > Trivially so for "extend" being inverse to "project". Not sure about
> > summarize. Summarize result extends the input relation with additional
> > "aggregate" column, and projecting the input relation to the "group by"
> > column at the same time. In the set symantics you have to say no more,
but
> > in the bug semantics I have to apply restriction to make rows
"distinct".
>
> Were the latter semantics a freudian slip? Technically SQL's select list
> isn't even project unless it includes distinct or group by, but I didn't
> want to seem too contrary.
>
>
> > > Table closure actually. Have you ever considered that SQL's cartesian
> > > product followed by restriction, if handled correctly, is a poor
cousin
> of
> > a
> > > relational join? Have you ever noted that it forces the effort to
> identify
> > > the common columns onto the user?
> >
> > Why is it such a big deal?
>
> Forcing users to perform easily automated tasks? Do you really have to
ask?
>
Allow me to join this thread. So far as I understand the "D" meta-language
and the Alphora implementation, a join is based on the naming of the columns
in the respective relations. This is something that is not to my liking: my
feeling is that naming might not be sufficiently consistent to use that
approach.
Perhaps the idea would be okay if the same team of people developed the
entire database, but in the not so uncommon situations where two groups of
people - say one frommanufacturing and one from accounting - each develop
their part, naming might give false joins. This is particularly so since
most languages have the same word meaning different things according to
context.
If I were to develop a relational queru language, I would prefer a natural
join command to depend not on names but on the logical dependencies in the
DBMS. Thus R join S would be meaningful if and only if the was a foreing key
constraint from R to S or vice versa.
Kind regards
Peter Koch Larsen
Received on Fri Mar 14 2003 - 12:51:59 CST
