Path: utzoo!utgpu!water!watmath!clyde!att!rutgers!tut.cis.ohio-state.edu!cwjcc!hal!ncoast!allbery
From: allbery@ncoast.UUCP (Brandon S. Allbery)
Newsgroups: comp.databases
Subject: Re: ORACLE on the cheap... questions
Message-ID: <11956@ncoast.UUCP>
Date: 29 Jul 88 02:24:25 GMT
References: <5165@dasys1.UUCP> <8208@ncoast.UUCP> <178@turbo.oracle.UUCP> <590@hscfvax.harvard.edu> <180@turbo.oracle.UUCP>
Reply-To: allbery@ncoast.UUCP (Brandon S. Allbery)
Followup-To: comp.databases
Organization: Cleveland Public Access UN*X, Cleveland, Oh
Lines: 112

As quoted from <180@turbo.oracle.UUCP> by rbradbur@oracle.UUCP (Robert Bradbury):
+---------------
| (who shall remain nameless); Unify later packaged and started publishing
| these numbers showing it as having much faster insert rates than the other
| RDBMS (without pointing out the much lower level interface it was using
| to perform these inserts -- yes, Virginia; we can append records to the
| database file faster than other people can parse and execute SQL statments...
| :-) ).  Oracle threatened UNIFY with legal action due to the violation of
+---------------

Why?  Because they were right?

I'm currently discussing this with an Informix TS type.  Frankly, whatever
supposed benefit you get from SQL is lost when you have to pass character
SQL statements down a pipe or through shared memory to be parsed at runtime
and then get the data back the same way.  (PIPE_TWO_TASK: is miserable.  But
at least you ship FAST_TWO_TASK: with the kernel:  to get the equivalent in
Informix one must buy Informix-Turbo.)  Not only is Unify's (and Informix
3.3's) database updating low level, but (in the case of Unify) the ESQL is
translated _at_compile_time_ into the same low-level C code... which makes
for blinding speed compared to runtime parsing of complex grammars.  (Network
hooks aren't that difficult, either, Unify has had UNIPROC for quite a while
now.  It passes requests, but *not* in the form of ASCII grammars.)

Do not make the assumption that people will accept loss of speed in return
for a *little* more portability.  A bytecode network interface is just as
amenable to an ANSI standard as SQL is, and it's faster because it doesn't
need to be parsed and the statements end up being smaller anyway.

+---------------
| This is *EXACTLY* the type of thing I was refering to in my original
| posting.  You *fail* to mention the versions which were being compared
| in this benchmark.  Oracle, Informix and Ingres have had a history of
| leapfrogging each other in performance benchmarks over the last 5 years.
+---------------

I would *love* to bench Informix 3.3 against Oracle based on this statement.
Maybe I will (of course I can't publish the results, but it should be
interesting nonetheless).  --Certainly an application that had been running
in 3.3 for years slowed down abruptly when moved into Oracle....  (Again,
SQL parsing and shipping data through (pipes|shared memory) has disastrous
effects on speed.  I expect Informix-SQL is no better.)

+---------------
| a recent benchmark done at PACBELL.  As Oracle was picked over the other
| vendors one would probably presume that the benchmark results were not
| as bad as the study you are quoting.
+---------------

We implemented the *same* application on the *same* machine in *four* DBMSes.
I don't think you want to hear the results, and neither will Informix because
they shatter a few of Mr. Sippl's cherished myths.  It is this which provided
the objective proof of what I had noticed on my own previously (i.e. SQL is
less efficient than low-level access).  I should like to try it in a few
others as well and see what happens; there are other considerations in the
use of SQL than just the need to parse it at runtime.

+---------------
| many of them) get a little testy when people present a picture of Oracle's
| performance which reflects past history more than current reality.
+---------------

But the future of the DBMS is, quite frankly, *slower* then the past.  At
least, so far; and while you can speed up the hardware to compensate the
older DBMSes will be ported to that new hardware and keep its lead.

+---------------
| if you want to know how your application will perform on these systems
| YOU MUST BENCHMARK YOUR APPLICATION.  And even then I'll bet that
| in a good percentage of the cases I can take your best efforts
| and beat the application, RDBMS and operating system with a stick and
| make your initial results look fairly silly.  (This is not to say
+---------------

...don't forget to look at the interface as well.  I tossed the Progress
Test Drive after trying to build some screens that turn out to be trivial
in both Accell/Generator and SQL*Forms.  In that case, speed is worthless if
you can't figure out how to implement the application in the first place.
(Note that recent releases of Progress are supposed to have a screen generator
in them, so this argument may or may not still apply).  Progress's frame
handling language -- a language similar to SQL in style -- is just another
nail in the coffin of those language types; it's perfectly possible to be
non-procedural without being opaque.  (Informix Ace, Unify RPT and Accell/
Language, and the database access code -- not involving frame descriptions --
of Progress are good examples of this brand of "semi-non-procedural" code
which gets the benefits of non-procedural code without the flaws.)

+---------------
| >   Some, Like Ingres, though, use the termcap syntax for this purpose,
| >   regardless of which operating system the product is running under.
| 
| Given how difficult TERMCAP is to maintain I wouldn't consider this
| a plus.  AT&T converted to TERMINFO to make it faster; they missed the
| boat though because terminal descriptions belong in a database.
+---------------

It *is* in a database.  So what if it's hierarchical instead of relational?
And the problem with using a relational DBMS for this is that nobody will be
bothered to design a simple DBMS that can be standard Unix; instead we're
all having C-ISAM shoved down our throats.  (A simple B-tree library and
intermediate-level database routines have been posted to comp.sources.misc;
if someone with a bit more savvy in B-trees wants to finish implementing
the delete code we wouldn't need to license the database from someone else.
Termcap, after all, doesn't exactly need to be blazingly fast at -- or even
capable of -- TP1.)

Just stirring up the hornet's nest. . . .

++Brandon
-- 
Brandon S. Allbery, uunet!marque!ncoast!allbery			DELPHI: ALLBERY
	    For comp.sources.misc send mail to ncoast!sources-misc