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

"Peter Koch Larsen" <pkl_at_mailme.dk> wrote in message news:3e732023$0$32010$edfadb0f_at_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?

No. I expect the people performing logical and physical design to have a clue about the stored relations in the database. How else can they do their jobs?

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

Nobody except the dba for the company who purchased the product. Are you seriously suggesting that such a dba should perform logical and physical design without any knowledge of the existing product's design or at least of its published application view?

Are you suggesting the purchasing company should use a foreign data model without any kind of application view for the company's additions?

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

The conceptual, logical and physical designs happen by themselves?!? Who does them? Elves?

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

You were not arguing for the SQL way of expressing joins. You promoted joins based on foreign key constraints.

I started this sub-thread by explaining what I find unpleasant about the SQL way of expressing joins. You can review it at the top of this message ending with "Forcing users to perform easily automated tasks? Do you really have to ask?"

> It might
> be slightly more inconvenient to use in some instances, but there are no
> limitations per se.

I disagree. The SQL way of doing things lacks cohesiveness, conceptual clarity, and it puts an inappropriate burden on users.

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

All the more reason to base joins on heading names: When the user renames the emp attribute of employee to mgr and the name attribute to mgr_name, the intention becomes very clear. The graphical tool can help the user by showing the connections between Certification and Position in the other example above; even though, no foreign key constraint exists between them. Received on Sat Mar 15 2003 - 16:52:44 CET