kemp@kaoa05.dec.com (02/04/88)
Newsgroups: comp.databasesp Path: decwrl!labrea!rutgers!bellcore!faline!ulysses!sfmag!sfsup!prjp Subject: network/relational Posted: 22 Jan 88 00:31:37 GMT Organization: AT&T-IS, Summit N.J. USA >Relational systems do indeed handle complex problems well. They fail (and >dismally at that) for certain applications (ones I vaguely termed "human"). I don't understand this point. I have seen or used Relational models being used in every business application with great success. Can you give me an example of a "human" system. >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. True... but often forgotten by those preaching scripture. Also I would liketo hear what criteria you would recommend be used to make the decision between implementation in each of the three environments. >Network systems suffer because of a lack of "trade schools" to teach you how >to design an application. So to for relational designs. I've seen some pretty bad stuff from people having no understanding of what they wanted to achieve or why ie no model OVEREMPHASIS on the theory of data modelling (in a relational world) or no theory. > 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). So true for relational design. I work almost exclusively with the relational model. The strength of the relational model is, as Codd demonstrated it is the simplest model for supporting a data architecture. And as I am sure you would agree "good engineering is simple engineering". What changes most often is that data are added to a structure, next the underlying definition of a data element and finally new structures (entities, tubles) are created or existing ones modified. If you maintain data independence in noramlized data structures, the thing that is easied to support is a change in procedure (which is trivial) and most difficult is the creation of a new entity. > 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). Actually what you are talking about appears to be "data independence" a concept that states that data should be completely separated from process. Because process changes at a different rate than the data. Data being very table, having a half life of years, and procedure being very unstable, changing every minute or two. The way you protect yourself from this the effects of thiis, and therefore minimize the need to restructure your database, is to have a robust model, keep the definitions atomic and ensure process is not imbedded in any definition. > Ideally, you should not even >need to know what DBMS or programming language you will be using. True. A robust model can be transported to multiple environments and not be impacted. It will retain its underlying structure. Though in practice some "denormalization" may occur for performance reasons or because of software constraints. The user should not care or have to care about size of machine, type of machine operating system etc. They should be able to, with a very simple protocal get to the data they need... When I pick up the phone it works and I can place the call I want. Do I care or need to care how this is achieved? >The real power of relational systems applies in cases where there is no model, >or where 1000 models might apply. Wrong, wrong, wrong. It is essential that the data model reflect the rules of the business it supports. The whole idea of the Third Normal Form (3NF) is based on the idea that you can specify a unique relational model for you data that will accurately reflect the business and its structure. > Data coming back from satellites might be a >good example -- who knows what you're going to want to do with it? You cannot just dump data in a heap on the floor. It has to be ordered and structured to support the demands you plan on placing on 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. You can (notice I said can, not should) take any set of data and structure it in 3NF. >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). I think you are making assumptions about language, you are assuming that there are no products that enable you to change a query in a rapid manner. That the cost of "writing" a query cannot be made so low that the cost of converting many such queries is considered trivial by the impacted user population (in our case, sometimes hundreds of people). > 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. Again, relation is deemed "sensible", and some would argue "proved" more robust then network. Further, in seven years of working with relational systems I have never seen an part of our environment "cough and die" just because of growth. Because of a major change in the underlying structure of the data, such that new entities had to be created, destroyed or data moved around, based on a managed RESTRUCTURING OF THE BUSINESS MODEL maybe, but growth? No. >Guess why network techniques underlay every "relational" system implementation >available today. That's right, there is a model there. Obviously I don't agree. The idea of the relational was proposed by Codd,and fostered by Date, Chen, et al. I suggest if you have not read them that you do so :-) > What aggravates me >about relational advocates is that they are "arrogant" enough to say that they >need the techniques, but you don't. Sorry don't understand ??????????? > 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). I see a lot of hand wringing by people that don't understand the issue and cannot understand the global trade-offs to be made between a multitude of factors, including but not limited to, hardware, software, user and programmer productivity, the rate of change and growth in the business and the rate of change in the underlying technology. If you measure performance the way my boss does then the issue is very simple. I (the mythical boss) have a problem, how long will it be until YOU (ie me) can get back to me (ie the Boss) with the answer to a problem I have now? To him, if I say half a day,(thats half a day to do the analysis, develop the query, analysis the results and prepare a recommendation) that is great. He doesn't care if I have subsecond response time or not. He will care if I discover the model, read system, does not support his problem and the answer will not be available for weeks. Besides if your need justifies more reponse time, make the investment and buy more (hardware). A simple cost benefit will document the payback. Otherwise, live with what you've got and quit complaining. > 2) Ease of change: poorly designed systems will be hard to change >(or use, for that matter). Right on. > 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. I will but an implementation of a relational architecture up against your network architecture and beat you on OVERALL price/performance, PARTICULARILY in an environment where change is the order of the day.-- (hows that for a clear statement of my *opinion*?) > 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. But if you can reduce the size of development staff you can reduce the administrative overhead. Since the overhead grows exponentially with the staff the reduction in staff, with the same or ideally improved level of service can be major. How many programmers to you need to keep around to work on all those little problems? Why should it take years to get through a project? What tasks can the users take ownership for? These are questions that havew nothing (or little) to do with the relational versus network debate, it has to do with 3GL, 4GL, CASE, reuseable code, screen generators, report writers, query languages etc, etc. Any and all of which can be implemented in either architecture. Administrivia can be reduced by pushing the work out to the users, athose with the "real" problems and giving them the tools to sove their own problems. This reduces the need for others to get involved, reduces all the otherwise required tools and therefore increases everyones probuctivity. One measure might be, for a given level of service (a difficult thing to measure I agree, what is the user/programmer ratio, or some other, similar measure. > 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. Hear! hear. 4GL and relational database is supposed to give you time to do the analysis and do it right. However programmers, Being programmers, like to get to the "important" stuff.. coding. "Get up and run, the direction is unimportant; but everyone will be impressed with the speed you are moving at. "Coding" is now running less then 20 percent of productive time (ie non administrivia time) in our shop, with analysis being as high as 90% of total time on some projects (these numbers exclude users, who bare the brunt of coding in our end user driven environment, and for them the answer is typically 90% analysis and 10% coding on any data access problem. Of course the other problem is getting management to understand the value of such an investment. My mythical boss may be very tolerate of taking half a day to answer a complex question and another may feel it is unreasonable to wait an hour for the same report under similar circumstances. > 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? I hope not. Most of the discussion I have watched for the last six months has been boring. I am not "into" DBASE III, or UNIX or C, or SQL (In fact in my mind, the last three don't even belong here, UNIX being an operating system, C and SQL being Languages.) Neil Kemp P.S. sorry for the questions imbedded in my reply.I would have preferred to present the net witha more complete response by discussing the gaps with you via E-mail, but for the life of me I cannot figure out how to get from here to there.