Re: SQL (was: Why using "Group By")
Date: Sun, 16 Mar 2003 12:39:56 +0100
Message-ID: <3e74628d$0$32000$edfadb0f_at_dread12.news.tele.dk>
"Bob Badour" <bbadour_at_golden.net> skrev i en meddelelse
news:xtIca.87$Cl6.10485819_at_mantis.golden.net...
> "Peter Koch Larsen" <pkl_at_mailme.dk> wrote in message
> news:3e732023$0$32010$edfadb0f_at_dread12.news.tele.dk...
> >
[snip]
> > > > >
> > > > > 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?
> >> > not always be the case. As an example, consider buying a shrink-wrapped
> > This might
> > 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?
I am not. Views would probably be added for the additions. That does not mean, however, that the original (base)relations will disappear.
> >
> > > > 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?
Several independent DBA's working on each their problem domain.
> >
> > > > 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?"
> >> > be slightly more inconvenient to use in some instances, but there are no
> > It might
> > limitations per se.
>
> I disagree. The SQL way of doing things lacks cohesiveness, conceptual
> clarity, and it puts an inappropriate burden on users.
Im not a big fan of SQL, either. But expressing the general join as R {product} S {where} <cond> is not counter-intuitive in my opinion. (names in {} are keywords of some kind). And if you do - out of convenience - define a {join}, I believe the appropriate definition would be to have R {join} S depend on the functional dependencies of that system, not on the names of the individual columns of R and S.
> >
> > 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.
>
It could. Even if there was no dependency between those two fields. Received on Sun Mar 16 2003 - 12:39:56 CET