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

From: Peter Koch Larsen <pkl_at_mailme.dk>
Date: Sat, 15 Mar 2003 13:44:19 +0100
Message-ID: <3e732023$0$32010$edfadb0f@dread12.news.tele.dk>

"Bob Badour" <bbadour_at_golden.net> skrev i en meddelelse news:E8qca.48$IB4.5176455_at_mantis.golden.net...
> "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?

So You expect everything to be "created" by just one authority? This might not always be the case. As an example, consider buying a shrink-wrapped product where all data is predefined. You might want to integrate the tables defined by that product together with your own application. But two different entities did create the two parts of the DBMS - with noone having a chance to coordinate anything.

>
>

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

Because tou assume there is such an entity as "the DBA". Might not always be realistic.

>
>


> > 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?

So relation R has two foreign keys on relation S? In that case the JOIN would be ambigeous and you would have to revert to the explicit method.

>

> 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?

I do not see how the SQL way of expressing joins limits anything. It might be slightly more inconvenient to use in some instances, but there are no limitations per se.
If we talk about ad hoc querying by endusers, they are not going to use SQL (or D or whatever text-oriented "programming language") anyway. Most probably, they will use some kind of graphical query language.

Kind regards
Peter Received on Sat Mar 15 2003 - 06:44:19 CST