Re: SQL (was: Why using "Group By")
Date: Fri, 14 Mar 2003 14:01:55 -0500
"Peter Koch Larsen" <pkl_at_mailme.dk> wrote in message
> "Bob Badour" <bbadour_at_golden.net> skrev i en meddelelse
> > "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...
> > > > 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
> 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
> in the respective relations. This is something that is not to my liking:
> feeling is that naming might not be sufficiently consistent to use that
> 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.
Since they would use different views of the database constructed by the DBA who completes the logical and physical designs, I don't know why this would happen.
> This is particularly so since
> most languages have the same word meaning different things according to
Yes. Context is important. A name in one application view can mean something different in another application view.
> 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
> constraint from R to S or vice versa.
How would the user express a query requesting employees who are MCSD certified and who work in Sales? The query evaluates a set of employees where a functional dependency incidentally exists, but I see no reason to enforce any functional dependencies between Certification and Position relations.
Wouldn't a requirement like the one you suggest limit the utility of the dbms to have many of the limitations of a network model dbms? Received on Fri Mar 14 2003 - 20:01:55 CET