Re: SQL (was: Why using "Group By")

"Peter Koch Larsen" <pkl_at_mailme.dk> wrote in message news:3e7224cf$0$32011$edfadb0f_at_dread12.news.tele.dk...
>
> "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...
> > > > 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.

Except for carelessness, why would it not be sufficiently consistent?

> 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
> context.

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
key
> constraint from R to S or vice versa.

What if there are multiple references? How would you handle the works_for example with two references to an employee relation?

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