prj@sfsup.UUCP (P.Jayne) (01/05/88)
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
eric@pyrps5 (Eric Bergan) (01/06/88)
In article <2557@sfsup.UUCP>, prj@sfsup.UUCP (P.Jayne) writes: > > >>(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. Have all the applications that you have worked on been static entities, that didn't change as you after you had initially designed the database? If a network database-based application suddenly needs to support a new query that it was not initially designed for (but has the data for), a significant redesign may be necessary. In a properly designed relational database, the data independence allows you to avoid this redesign. Further, it is not at all unusual, after the application has gone into production, for new requirements develop. These are particularly nasty, since you may not be able to afford the production down-time to reorganize a network database to support the new requirements. With a relational database, the only significant change might be the creation of new indices, and some of the current vendors even allow that to be done without down time for the database. > >> 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? We all know of failures for almost any aspect of computer usage. This does not prove that the technology is "bad". Just as there are good and bad systems developed based on network databases, there are good and bad systems developed upon relational databases. Now, if you could prove that significantly more bad systems are developed under relational databases than under network databases, you might have a stronger point.
UH2@PSUVM.BITNET (Lee Sailer) (01/06/88)
One factor in the change from Network to Relational approaches is that
new ideas from R migrate "backwards" to N approaches. For example, an
emphasis on keeping the logical and physical levels separate, or
implementing entities that are more or less in 3NF. Because these ideas
have been accepted by N users, the need to convert to R systems is less
crucial.
I think this parallels the use of *structure* in COBOL programs, for
example. Much of what is good about structured, top-down, stepwise
refinement approaches to programming and design is easier to TEACH in
Pascal, say, but can be used by programmers in any language. Likewise,
the reasons that Codd (to name just one) gives to justify design
decisions in the R model can often times be used by N model implementors
to improve their systems.