From: briand@anasaz (Brian Douglass)
Newsgroups: comp.databases
Subject: Re: Relational Systems set back DP by at least 10 yrs.
Date: 11 Apr 92 23:57:05 GMT
Organization: Anasazi, Inc.  Phoenix, Az

In article <1992Apr10.004118.15114@hal.com> crash@hal.com (Chris Craddock) writes:
>Having made a career out of large systems engineering, I can only
>agree with the guy who said this about relational systems, but
>what the heck, its been a damn fine living...
>
>However, there are some fundamental reasons for their failure.

Just wanting to add my $.02 to this, a very key point was missed by the
original poster and Mr. Craddock.  That is the biggest strength of an RDBMS
over a flat-file system is not in insertion speed, but rather the building
of complex data relations between tables of records.  The ability to ask
"What if" queries is the inherent strength of an RDBMS, not flat I/O
ability in a real-time data acquistion application.

>SECOND: relational solutions are utterly unforgiving of poor design.
>Any solution (such as VSAM or DL/1) which provides (and relies upon)
>physical pointers is always going to beat the snot out of an RDBMS
>which has no positional information. Accordingly, you could almost
>slap together any grotty old application and database design and it
>would work just fine. However, as many early adopters have discovered
>to their dismay, a great many real world applications are simply not
>executable by RDBMS's without careful design and *INTENSIVE* tuning.

RDBMs and accompaning tools have elevated the state of Decision Support
System applications.  No longer is the data "trapped" by what extra keys a
programmer may or may not have put into record layout, but rather with a
superior design (I prefer BCNF myself), I can manufacturer vertually any
kind of relationship the user wants (including those that don't exist 8-).
The unforgiving nature of an RDBMS realized when non-Relational approaches
are applied to an RDBMS.  However, when fully Relational approaches are
used, and the design is good, the flexibility obtained is a thing of
beauty.

I've designed and built systems that are heavy on DSS (insurance
statistical reporting) and heavy on performance (ATM style OLTP), and the
rule of thumb I use, is use the right file I/O approach to solve the
problem.  If you don't need instaneous reporting of data, flat-file is a
great approach.  If you do need group reporting, especially ad-hoc inquiry
(report the summary amount of claims submitted by month, cross referenced
to the amount paid in which subsequent months), and RBMS can make simple
work of it.

What I'm trying to say, is that no one solution is perfect for all
problems.  Always the right solution to the problem, instead of trying to
apply one solution (RDBMS) to all problems (i.e. Bill of Materials,
possible, but such a pain!).


>THIRD: relational solutions (just like OO* and CASE before it) were
>heavily over-sold and over-hyped by unscrupulous vendors. The poor
>customers were told they no longer needed database designers, or
>administrators and that users could code applications ten times as
>fast. The carrot was just too tempting and they bought it in droves.

When it's done right, it does work.  The trouble is, people take a
piecemeal approach instead of systemic.  In a recent PBS show
called "Quality or Else" an example was given of a manufacturer that had
bought a robotic welder on the promise it could weld ten times faster.
Instead, production came to a halt.  Upon examination it was learned that
the underlying systems that produced the components for the finish welder
were not within specks.  Human welders just worked around this deficiency
(Ralph, where's that ball-pean hammer?) and did the welding.  The robotic
welder couldn't do this and just rejected everything.

CASE, 4GL, etc, are all part of a systemic method to better quality and
shorter development cycles.  But to through just bits and pieces of the
solution at the problem, nothing but aggravation is realized.  I used to
Yourdon DFD's by hand, because there was no program do them (Government
contracts).  Now I have a tool that will do what used to take a week an
hour.

All of these tools have a learning curve (that the salemen do fail to
mention) that DOES slow things down at first.  But once mastered, you can
produce faster than before.  Afterall, how long did it take to right your
first really complicated C program (> 1000 lines), and how long would that
same program take you now?  CASE, RDBMS, 4GL, Design Methodoligies, etc,
they're all just tools that take time to master.

>The reality was that they could code slightly faster, but that they 
>ended up spending at least ten times longer debugging, redesigning
>and tuning the application.
>
>I installed one of the first production DB2 systems outside of the IBM 
>labs in 1984 and I've been working with it and other RDBMS systems
>pretty much continuously since then. On the basis of personal experience
>I would say that the result of point three above has been a net decline
>in productivity. 
>
>Cost wise, there have been hundreds, or thousands of hardware upgrades
>driven solely by the need for more relational mips. It is fair to say
>that the price/performance ratio of databases has declined severely
>over this time. 
>
>Is this really "progress" ?  I sorta doubt it.

Hey, I've never had to write a line of COBOL or assembly in my life.  I
think we're making progress.

One final note, this whole argument reminds me of the race between a steam
powered train and horse.  The train lost and everyone laughed at its
inventor.  But the work continued and eventually the horse was supplanted
by the steam-engine, and then it too by the internal combustion engine.  I
do think this is progress.

-- 
"You want to know what's scary?  The Third World has 12 new members and
some of them are nuclear armed!"  Former US intelligence officer.

Brian Douglass			briand%anasaz.UUCP@asuvax.eas.asu.edu
				602-870-3330 X657