prj@sfsup.UUCP (P.Jayne) (01/22/88)
The pro-pre-non-relational etc. discussion seems to be dying down a bit, so I thought I'd say what I really believe. Hope it provokes as much discussion as my snotty early postings (glad no one seemed to be offended). Relational systems do indeed handle complex problems well. They fail (and dismally at that) for certain applications (ones I vaguely termed "human"). However, "network" (I hate this silly term) systems also fail dismally when they are applied to the wrong applications. Finally, both will cause untold horrors when they are implemented poorly. Network systems suffer because of a lack of "trade schools" to teach you how to design an application. Only one person (an e-mail only respondent) showed the slightest understanding of how to employ network techniques. Don't worry, I won't bore you discussing this too long. The trick is that you design your application by using a model -- if you do it well, the model is only hard to change in places where the enterprise you are "computerizing" is hard to change. This insulates you from most difficulties (but few people spend the design time necessary to do it right). The other trick is that if you have N programs in a network application, exactly one knows about the data structure, or even what DBMS you are using. If not, all anti-network flames apply to your design. This too, requires time in the design stage(s). Ideally, you should not even need to know what DBMS or programming language you will be using. The real power of relational systems applies in cases where there is no model, or where 1000 models might apply. Data coming back from satellites might be a good example -- who knows what you're going to want to do with it? What model could possibly help you understand how to organize...what? There are other cases (well-known "package" applications, like Accounts Payable maybe) where relational can also have advantages over network. If you should be using network and you use relational, what will happen is that the structure you thought you had flattened will infest your canned queries, and when the application changes you will have a fine time rewriting them all (note I said the application, not your tables). If you try to use network where a relational approach is sensible, you will construct some artificial model that will cough and die when the application grows. Guess why network techniques underly every "relational" system implementation available today. That's right, there is a model there. What aggravates me about relational advocates is that they are "arrogant" enough to say that they need the techniques, but you don't. Physician, heal thyself. My other main complaint centers on the idea that relational is always better than network, making the latter obsolete. Dinosaurs should be so obsolete -- we'd all be lizards, not mammals. There are two straw men that took some pounding in the discussion, and I'd like to give them a break: 1) Relational advocates seem to be doing a lot of hand-wringing about speed, though no one else raised the issue. Performance is a non-issue, it will get better (esp. considering the efforts being made on that problem). 2) Ease of change: poorly designed systems will be hard to change (or use, for that matter). Network is no worse than relational otherwise, and even if it were, consider this: in a large (complex?) application, the barrier to quick turnaround is administrative, not technical. In the worst, crankiest, hardest to change system I ever worked on, average developers found and fixed bugs in a matter of hours, days, or at worst, weeks. Compare this to the two years it took to get through test procedures, documentation, training, etc. Cutting coding/debugging time by 90% would save 0% overall. Finally, the idea that rushing development is a good thing should have a stake driven through its heart. Sure, I prefer tools that are easy to use and save me time, but again, coding is not what takes up most of the time I spend designing an application. Comments? Or do we have to go back to reading all those boring discussions of how hard it is to do simple things in SQL? Paul Jayne