Re: SQL (was: Why using "Group By")
Date: Fri, 14 Mar 2003 19:51:59 +0100
"Bob Badour" <bbadour_at_golden.net> skrev i en meddelelse
> "Mikito Harakiri" <mikharakiri_at_ywho.com> wrote in message
> > "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,
> > in the bug semantics I have to apply restriction to make rows
> 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
> > a
> > > relational join? Have you ever noted that it forces the effort to
> > > 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
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.
Peter Koch Larsen Received on Fri Mar 14 2003 - 19:51:59 CET