Re: SQL (was: Why using "Group By")
Date: Fri, 14 Mar 2003 13:21:16 -0500
"Tibor Karaszi" <tibor_not_pressed_ham_.karaszi_at_cornerstone.se> wrote in
> Tibor Karaszi
> "Bob Badour" <bbadour_at_golden.net> wrote in message
> > "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
> > > 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
> > > > product followed by restriction, if handled correctly, is a poor
> > 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
> ANSI SQL has a join type (NATURAL) where the engine automatically joins
> common column names. I don't think that it is widely implemented, though.
> I'd prefer if we had such an option for FOREIGN KEYs.
I am not sure what you mean, Tibor. If one has a works_for relation with emp and mgr columns that both reference an employee relation, how would one express this foreign key join? And what criteria would govern the join?
The ANSI NATURAL JOIN clause was a relatively recent afterthought that does not erase the problems caused by originally choosing extended cartesian product as the basis of queries. Received on Fri Mar 14 2003 - 19:21:16 CET