Path: utzoo!mnetor!uunet!husc6!hao!oddjob!mimsy!umd5!uvaarpa!mcnc!rutgers!bellcore!faline!ulysses!sfmag!sfsup!prj
From: prj@sfsup.UUCP (P.Jayne)
Newsgroups: comp.databases
Subject: relational technology flames
Message-ID: <2557@sfsup.UUCP>
Date: 5 Jan 88 00:33:32 GMT
Organization: AT&T-IS, Summit N.J. USA
Lines: 118


Thanks for the flames.  I deleted lots of filler, hope I didn't overlook
any actual points.

 > It's too bad that he hasn't been "doing database" for 15 years.  Then he 
 > could have joined the large and vocal group who claimed that dbms's simply
 > wouldn't stand up to plain old Cobol and assembler.  For the same reasons we
 > are now told that relational is inferior......

 >   greg pavlov, fstrf, amherst, ny.

	I said "over ten years" greg.  I've worked in CICS (COBOL and assembler)
in IMS (I used assembler and PL/1;  others, I can assure you, used COBOL).
I also used COBOL and assembler with Burrough's Disk ForteII DBMS long ago.
Did you think those systems worked without programs?
	By the way, I didn't say 'relational is inferior' to anything.

>>From: ok@quintus.UUCP (Richard A. O'Keefe)
>>Summary: SQL =/= Relational Databases

>>Anything which a network data base can do
>>a relational data base should be able to do.

Should?  That's bold of you.  Well, so can a Turing machine.  Whoop-te-do.

>>(The difference between a network data base and a relational
>>data base is that in a network data base some of the joins have already
>>been done for you, and most of the rest are nearly impossible to do.)

	More-or-less.  This is part of what should help you choose one over
the other.  Most posters ignored me when I said relational DBMSs had
their niche.  You make a lot of queries of the "What employees under me
make more than I do and are left-handed" variety, you use relational.
As far as things being "nearly impossible to do" in a network database,
let's not confuse poor design with choice of DBMS.  I have never had to say
"no, that's too hard to do" because of say, IMS;  the reason things can't
change rapidly is administrative, not technical.  Most people don't see
this at all -- the coding is the easy part.  Sorry, hackers.

>>Please don't confuse SQL with relational data bases. 

	Ah, a major point!  Alas, the world beat me to it.  Like it or not,
SQL is the standard interface to "relational" databases.  I can certainly agree
that Prolog would have been a better choice, but as you say later, it isn't
really 'relational.'

>	If relational data base systems were all they claim to be,
>	many or most network systems would have been converted by now.

>> This is just plain false.  It is extremely rare for ANY complex
>> application of ANY sort to be "converted".  ["Proof" deleted]
 
	Converted to what?  Across vendors?  Not rare.  Actually, I was being
pretty obscure here.  What I meant was that if the application is up and
running, then the analysis has been done.  You know the entities, you know the
relations, you know the queries, etc.  If you can sit down and produce an
application from scratch in a few months with a 4GL, it will surely be easier
if all the up-front design has been done, no?

>> It simply isn't true that relational systems "fail rather dismally"
>> when they meet anything complex.

	Ever heard of the New Jersey Division of Motor Vehicles?

>> [Spelling: it's interpretEr, not interpretOr.]

	Got me again.  It is embarrassing to do this in the same paragraph
that I am praising word processors (er, that 'or' is right, isn't it?).

>> I don't see why I should forget compilers.  (Much praise of Prolog deleted).

	I think you saw my point, but I don't quite see yours. 

>> It is important that you should not make the mistake of identifying
>> SQL with the relational approach.  The better you understand the
>> relational approach, the worse you will like SQL.

	No real argument, but it wasn't my mistake.  Try selling a 'relational'
DBMS that doesn't support SQL if you don't believe me.

>>From: mjr@well.UUCP (Matthew Rapaport)

> There aren't a lot of defenders of pre-relational DBMSs out there it seems.

>> Implicit in this argument is the mistaken supposition that what is 
>> currently "out there" representing relational DBMSs in real products is
>> all there is to the relational model!  Consider that the BEST such
>> products implement only 50% of the model.  Before too much criticism,
>> it would be best to learn what the model really provides for, and ask
>> why vendors have never provided it!

	And who is going to tell us, when a leading proponent of relational
(sorry I can't remember if it was Codd or Date) says network is obsolete?
Now you tell me there is nothing else "out there"!  Perhaps one advantage of
non-relational systems is that they don't have to bow to some definition.

From: daveb@geac.UUCP (David Collier-Brown)

>>  Rather than continuing with a mixed factual/religious debate, I'm
>> just going to throw in a comment re use "out there":

>>  Research in database theory has yielded the Entity-Relation model,

	I've done a fair amount of work with this model.  There are others.
See January '87 ACM for a simple E/R model, and a cogent argument against
using SQL to implement it.  (The authors like Prolog, by the way.)

>>  Computer manufacturers who understand the subset of the relational
>> and network models which are co-representable have provided
>> "relational access managers" for existing network databases...

	Can't comment.  I work on one.

	My original comment that there aren't many defenders of pre-relational
DBMSs is sure true.  Every response I've received has been pro-relational.
If no one joins me, I'm going to have to admit I'm tilting at windmills.

	Paul Jayne