prj@sfsup.UUCP (P.Jayne) (01/01/88)
There aren't a lot of defenders of pre-relational DBMSs out there it seems. I can no longer resist jumping into this. I've been doing database and datacomm for over ten years now, and I've heard that: Computers are going to solve your data storage/retrieval problems. COBOL is going to solve your data storage/retrieval problems. CICS is going to solve... IMS is going to solve... Flash! Relational technology is going to solve... The Brooklyn Bridge is up for sale again, and there are lots of buyers. Well, Bradshaw, it's like this: Complex problems don't become simple because we want easy answers. Arithmetic is a lot easier to use than Calculus, but sometimes you need Calculus and even more complicated methods. The big lie of Relational Technology is that all human applications can be reduced to a set of tables and a set of clever queries. Data complexity doesn't disappear when you hide it in the form of torturous SQL statements. Relational DBMSs succeed when they fill the niche of fairly easy systems that aren't worth the expense of doing a full-blown application. They fail rather dismally when they meet up with anything complex. If they were all they claim to be, many or most network systems would have been converted by now. In fact, no large complex system has ever been converted (corrections, please) to a Relational DBMS -- the usual approach is to do "new" development on the new system (which means the easy stuff they didn't have time for). If you would like to get a feel for the idea, consider how your life would be if the computer systems you use today were "relational". Forget word processing. Forget compilers. Oh yes, and how many SQL interpretors are written in SQL? Relational systems have a definite place in the market and they always will. But don't expect them to get you to Brooklyn. Paul Jayne sfsup!prj
pavlov@hscfvax.harvard.edu (G.Pavlov) (01/01/88)
In article <2550@sfsup.UUCP>, prj@sfsup.UUCP (P.Jayne) writes: > There aren't a lot of defenders of pre-relational DBMSs out there it seems. > I can no longer resist jumping into this. I've been doing database and > datacomm for over ten years now, .................... > > > The Brooklyn Bridge is up for sale again, and there are lots of buyers... > ... (treatise on why relational dbms's don't cut it) 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.
ok@quintus.UUCP (Richard A. O'Keefe) (01/02/88)
In article <2550@sfsup.UUCP>, prj@sfsup.UUCP (Paul Jayne) flames against relational databases. He says a number of things: > Complex problems don't become simple because we want easy answers. Absolutely right. > The big lie of Relational Technology is that all human applications > can be reduced to a set of tables and a set of clever queries. There's a half truth in here. Anything which a network data base can do a relational data base should be able to do. I commend to you the book Relational Database, selected writings C. J. Date Addison-Wesley, 1986 ISBN 0-201-14196-5 Actually, everything of Date's that I've seen is good value. I'm not quite sure what Jayne means by "human applications", but I'll agree that most human affairs are not adequately treated by any sort of data base. (There was a rather good critique of the "British Nationality Act" program in the Computer Journal a couple of years ago; I'm sorry I can't supply the reference.) But I repeat, this applies to a network data base just as well. (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.) > Data complexity doesn't disappear when you hide it in the form of > torturous SQL statements. [Spelling: did he mean 'tortuous' = "involved, not straightforward"?] Please don't confuse SQL with relational data bases. SQL is to relational data bases as IBM PCs are to computers: in both cases you have something which *looks* simple and has encouraged more people to use this kind of tool and which has even facilitated portability of applications, but which is a design *disaster*. I am a dyed-in-the-wool logic/relational data base/Prolog enthusiast, and I find SQL unbelievably clumsy for even the simplest query. As for anything complicated, ack thpt. As Date points out, SQL doesn't even support primary keys, which are to relational data bases what links are to network data bases. > Relational DBMSs succeed when they fill the niche of fairly easy systems that > aren't worth the expense of doing a full-blown application. They fail rather > dismally when they meet up with anything complex. If they were all they claim > to be, many or most network systems would have been converted by now. In fact, > no large complex system has ever been converted (corrections, please) to a > Relational DBMS -- the usual approach is to do "new" development on the new > system (which means the easy stuff they didn't have time for). Look at that third sentence: > 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". Conversion is not free: the cost of doing a conversion can easily exceed the benefits of having the result. Then there is another point. Suppose we have a problem P and two methods M1 and M2. Solving P using M1 leads to a solution S1. Solving P using M2 leads to a solution S2. Suppose that there is reason to believe that S2 would be clearly superior to S1, but that we already have S1. It may be *impossible* to convert S1 to S2. (S1 may have ignored characteristics of P that S2 needs.) It may even be the case that there is no-one around any more who recalls clearly what P was, or how S1 was derived from it. So it may not be possible/worthwhile producing S2 *now*, even though it would have been better if M2 had been available originally. Chapter 12 of Date's book explains why it would be difficult to convert IMS applications to SQL (basically, while SQL is retarded, IMS is totally insane). Paul Jayne is actually praising relational data bases here. The first and last sentences of that paragraph above are an admission that the cost of developing an application in a non-relational system may be too high to do even "easy stuff". What a condemnation! It simply isn't true that relational systems "fail rather dismally" when they meet anything complex. It is precisely when you have complicated *problems* that you need *tools* of the utmost simplicity and reliability. Whatever the reliability of SQL, it is not simple. I can readily believe that SQL is hard to use for hard problems. But that it is not because it presents the relational model faithfully, but because it DOESN'T. > If you would like to get a feel for the idea, consider how your life would > be if the computer systems you use today were "relational". Forget word > processing. Forget compilers. Oh yes, and how many SQL interpretors are > written in SQL? Relational systems have a definite place in the market and > they always will. But don't expect them to get you to Brooklyn. [Spelling: it's interpretEr, not interpretOr.] I don't see why I should forget compilers. The programming language I use most is Prolog. Admittedly that is more (and less) than relational, but it is ideally suited to writing compilers. Our Prolog compiler is written in Prolog, and while a lot of it is recursive marching down lists and such, there are a lot of tables in it. There are supposed to be ADA [ADA is a trademark of the Dud UFO] programming environments which keep information about ADA programs in relational form. The Interlisp programming environment has an extremely convenient tool called Masterscope which is basically a front-end to a small relational data base of dynamically maintained cross-reference information. I often use UNIX tools (awk, comm, join, sort) to maintain smallish (~10,000 records) data sets. These tools aren't a proper relational data base system, but they come close enough for the relational model to be a good way to think about them. Using a non-relational system would be a nightmare. Mind you, none of these things uses SQL, which would also be a nightmare. But then SQL =/= Relational. Let me give you some quotations from Date's book (chapter 14): "it cannot be denied that SQL in its present form leaves rather a lot to be desired--even that, in some important respects, it fails to realize the full potential of the relational model." "the user may have to expand time and effort transforming the 'natural' formulation of a given query into some different, and arguably less 'natural', representation. " (of the built-in functions) "Frankly, there is so much confusion in this area that it is difficult to criticize it coherently." 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.
mjr@well.UUCP (Matthew Rapaport) (01/02/88)
In article <495@hscfvax.harvard.edu> pavlov@hscfvax.harvard.edu (G.Pavlov) writes: >In article <2550@sfsup.UUCP>, prj@sfsup.UUCP (P.Jayne) writes: > 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! Matthew Rapaport mjr@well [ptsfa!well!mjr]
daveb@geac.UUCP (David Collier-Brown) (01/03/88)
>In article <2550@sfsup.UUCP>, prj@sfsup.UUCP (P.Jayne) writes: >> There aren't a lot of defenders of pre-relational DBMSs out there it seems. >> I can no longer resist jumping into this. I've been doing database and >> datacomm for over ten years now, .................... >> >> The Brooklyn Bridge is up for sale again, and there are lots of buyers... >> ... (treatise on why relational dbms's don't cut it) 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, (or the entity-category-relation model) which subsumes the "network" and "relational" models, and points out areas where they both fall down. Wait a while, there's a new religion coming! ((:-)) There's also an implementation of an e-r database manager in existance (Zim, from a company in Ottawa). 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, which provide the illusion of being able to do most of the relational operations on fairly broad views of network databases. The best example is argueably (Honeywell-) Bull although other manufacturers and dbms vendors also are trying to catch up... -- David Collier-Brown. {mnetor|yetti|utgpu}!geac!daveb Geac Computers International Inc., | Computer Science loses its 350 Steelcase Road,Markham, Ontario, | memory (if not its mind) CANADA, L3R 1B3 (416) 475-0525 x3279 | every 6 months.
john@geac.UUCP (John Henshaw) (01/04/88)
In article <2550@sfsup.UUCP>, prj@sfsup.UUCP (P.Jayne) writes: > [stuff] > Flash! Relational technology is going to solve... ^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^ This is a reference to a subject. No problem. > [more stuff] > The big lie of Relational Technology is that all human applications ^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^ This is the name of a major relational database vendor. (Notice the captialization?) I hope that this is a mistake. -john- -- John Henshaw, (mnetor, yetti, utgpu !geac!john) Geac Computers Ltd. "Relax. The collapse of the universe and all Markham, Ontario, Canada, eh? life as we know it, could only kill you once."