Re: SQL (was: Why using "Group By")
Date: Sat, 15 Mar 2003 10:52:44 -0500
"Peter Koch Larsen" <pkl_at_mailme.dk> wrote in message
> "Bob Badour" <bbadour_at_golden.net> skrev i en meddelelse
> > "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
> > > > 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
> > > ask?
> > > >
> > > Allow me to join this thread. So far as I understand the "D"
> > > 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
> > my
> > > feeling is that naming might not be sufficiently consistent to use
> > > 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
> defined by that product together with your own application. But two
> different entities did create the two parts of the DBMS - with noone
> 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?
> > > Perhaps the idea would be okay if the same team of people developed
> > > entire database, but in the not so uncommon situations where two
> > > people - say one frommanufacturing and one from accounting - each
> > > their part, naming might give false joins.
> > Since they would use different views of the database constructed by the
> > who completes the logical and physical designs, I don't know why this
> > happen.
> Because tou assume there is such an entity as "the DBA". Might not always
> > > This is particularly so since
> > > most languages have the same word meaning different things according
> > > context.
> > Yes. Context is important. A name in one application view can mean
> > different in another application view.
> > > If I were to develop a relational queru language, I would prefer a
> > > join command to depend not on names but on the logical dependencies in
> > > DBMS. Thus R join S would be meaningful if and only if the was a
> > key
> > > constraint from R to S or vice versa.
> > What if there are multiple references? How would you handle the
> > 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
> > 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.
> If we talk about ad hoc querying by endusers, they are not going to use
> (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