Path: utzoo!attcan!uunet!wuarchive!usc!snorkelwacker!apple!rutgers!att!ulysses!swfc
From: swfc@ulysses.att.com (Shu-Wie F Chen)
Newsgroups: comp.databases
Subject: Re: Is RDBMS unproven technology?  (Flames to follow....)
Message-ID: <13579@ulysses.att.com>
Date: 13 Aug 90 14:42:35 GMT
References: <1073@ashton.UUCP> <10371@sybase.sybase.com> <13532@ulysses.att.com> <10419@sybase.sybase.com> <13545@ulysses.att.com> <10494@sybase.sybase.com>
Sender: netnews@ulysses.att.com
Reply-To: swfc@ulysses.att.com (Shu-Wie F Chen)
Organization: AT&T Bell Labs
Lines: 123

In article <10494@sybase.sybase.com>, tim@ohday.sybase.com (Tim Wood) writes:
|>In article <13545@ulysses.att.com> swfc@ulysses.att.com (Shu-Wie F
Chen) writes:
|>>In article <10419@sybase.sybase.com>, tim@ohday.sybase.com (Tim Wood)
writes:
|>>|>In article <13532@ulysses.att.com> swfc@ulysses.att.com (Shu-Wie F
|>>Chen) writes:
|>>|>>In article <10371@sybase.sybase.com>, tim@ohday.sybase.com (Tim Wood)
|>>
|>>If you are talking about end users and canned applications, the model
|>>used isn't that important.  If you talk about the programmers who
|>>implement the canned application, then it is a different story. 
|>>Frankly, I am now confused.  Your previous arguments made sense for
|>>application programmers, but now you say you were really talking about
|>>end users.
|>
|>Making it very simple:
|>The relational model eases application development.  This tends to
|>encourage application development.  So the app. programmer and
|>the users benefit: the users get more needs met because
|>the app. programmer's job is easier because the relational model makes
|>app. writing easier.
|>

I agree...

|>>Well, have there [b]een any released competitive products (by ...
|>>competitive, I don't mean better than other *relational* DBMSs, but
|>>better than any *other* DBMSs)?
|>
|>Sure.  Relational has made the metrics of non-procedural access and
|>data independence part of the "competitiveness" equation.  RDBMS's
|>are competitive because people are buying them.  They are now
|>competing on another crucial metric, performance, so making navigational
|>systems even less attractive.
|>

Okay.  Though I was expecting the names of the released products with
high performance, I agree with your statement.

|>>|>>... [J]oins are a real big performance killer for relational systems.  
|>>|>Not if they are pre-optimized or pre-computed.
|>>What do you mean by pre-optimized or pre-computed?  What if I performed
|>>a join that was not pre-optimized or pre-computed?
|>
|>Pre-optimized: the query processing strategy is determined and that
|>strategy is saved in the DBMS in a pre-compiled form.  The DBMS needs
|>merely to execute the strategy to obtain the results.  Pre-computed:
|>the RESULTS (not just the strategy for obtaining them) are saved
|>somewhere (in or out of the DBMS) saving the need to recompute them.  A

Yes, pre-optimized and pre-computed queries will definitely be wins. 
But with respect to pre-optimized queries as a solution to improving
joins performance, I had thought that the overhead came from the
*execution* of the strategy, not the determination of the strategy. 
This really is a minor quibbling point on my part, the argument that a
compiled program runs faster than an interpreted one is true regardless
of whether the program contains joins.

[some deleted stuff about ad-hoc queries, scalability of RDBMSs]

|>
|>>|>Hmm, I've been developing the opinion that query compilation is a largely
|>>|>solved problem (cost-based optimizers, etc.), but that fundamental things
|>>|>like I/O management and access methods policies need a lot more work
|>>|>in RDBMS.  So sounds like we have a good discussion ahead of us :-) .
|>>I/O management and access methods policies are orthogonal to the data
|>>model.  These issues are just as important in navigational models.
|>
|>Of course, but these issues haven't been as well addressed in relational
|>models, and they are the ones (in most cases) that are hindering 
|>the ability of relational systems to scale well.  The fact is,
|>decreasing numbers of people are interested anymore in making navigational
|>systems faster.  
|>

I've been using navigational to mean hierarchical and network DBMSs.  It
is true that there is decreasing interest in making these systems
faster.  However, there is increasing interest in object-oriented
systems which are inherently navigational because of the
class-composition hierarchy. (This does not imply that there can not be
non-navigational components.)  This discussion is leading to my last
paragraph further down...


|>>The reason I suggested query compilation as a point of study is that in
|>>navigational systems, [ good summary of the application programming
|>>issues deleted ].  [But in relational, programmers ]
|>>are dependent on the query compiler to map their logical view and
|>>operations to physical operations.  I don't believe current compilers
|>>have reached the expertise of [human] coders in performing this mapping.
|>
|>Probably not.  The important ($) question for most users is, do today's
|>optimizers do a GOOD ENOUGH job on ENOUGH queries, without doing
|>a HORRIBLE job on nearly ANY query.  The more decision support (ie ad-hoc
|>queries) an organization does, the more important the optimizer will be.
|>However, a decent optimizer has become a check-off item for any RDBMS today,
|>as it should be: that is one of the things that allows them to perform
|>at all on those easily-written (but sometimes hard to answer) ad-hoc queries.
|>-Tim
|>---

As far as I can tell, we are agreeing that RDBMS is a proven technology
that has matured quite nicely into commercial products.  It is not
perfect for all applications (e.g. CAD/CAM, software programming
environments, gigantic IMS databases).  There remains work to be done on
improving performance.

The new question is: what comes next?

For starters, I'll cite two references:

1. Third-Generation Data Base System Manifesto by the Committee for
Advanced DBMS Function (Stonebraker, Rowe, Lindsay, Gray, Carey, Brodie,
Bernstein, Beech).

2. The Object-Oriented Database System Manifesto by Atkinson, Bancilhon,
DeWitt, Dittrich, Maier, and Zdonick.

Any comments?

*swfc