Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!rutgers!gatech!hubcap!ncrcae!ncr-sd!hp-sdd!hplabs!oracle!bradbury
From: bradbury@oracle.UUCP (Robert Bradbury)
Newsgroups: comp.databases
Subject: Re: Quality of Oracle Doc
Message-ID: <325@oracle.UUCP>
Date: Thu, 10-Sep-87 11:26:25 EDT
Article-I.D.: oracle.325
Posted: Thu Sep 10 11:26:25 1987
Date-Received: Sat, 12-Sep-87 09:30:39 EDT
References: <195@bernina.UUCP>
Organization: Oracle Corporation, Belmont, CA
Lines: 55
Summary: Documentation errors, SQL interface and performance

In article <195@bernina.UUCP>, marti@ethz.UUCP (Robert Marti) writes:
> I am currently studiyng call interfaces to DBMSs and have been
> looking into the Oracle Pro*C Users' Guide, Version 1.1.  Their
> C call interface looks more or less OK, but -- to put it mildly
> -- the quality of the documentation did not impress me at all.
> 
>    ... examples of the problems ...
> 
> All I can say is that this kind of documentation doesn't instill a
> great deal of confidence about the quality of Oracle products into  
> me.  Should it?
>
One should not draw parallels between code quality and documentation
quality in any organization.  They are almost always done by different
groups with different managers (in organizations with any size).
I've forwarded your comments to the Product Line Manager responsible
for the documentation and will personally rake him over the coals
for not having a programmer review the final print of the documentation.

As a general recomendation people planning to interface from a
programming language to a RDBMS should use the embedded SQL
syntax which is documented in the ANSI X3H2 SQL standard.
(I'm not sure if there is an ISO reference number).
Using embedded SQL results in a fairly portable application
program which you could move from DBMS vendor to DBMS vendor
as the RDBMS performance wheel turns.  In practice this
isn't possible right now because of minor differences
in vendors embedded SQL but it is the direction in which we
all are headed.

Using a function call interface locks you into one vendors product.
(Of course if you think IMS or MVS are good things to have around
 then you probably would prefer function call interfaces :-))

People who read advertisements or benchmarks with performance
figures should make sure they determine what interface is
used to the database.  Several RDBMS vendors have low
level interfaces which can result in higher performance
than an embedded SQL interface.  Such interfaces are
likely to violate Codd's "Nonsubversion" rule and therefore
disqualify the product as a "relational" DBMS.

With Oracle we recomend that people use the embedded SQL interface
as it will generally provide better performance than the function
call interface.  This is because the embedded SQL interface makes
use of an undocumented interface which can insert/retrieve multiple
rows at a time.  The interface is undocumented to allow us flexibility
in optimizing it and to eliminate the potential for support headaches
with customers using a complicated interface.  (It also eliminates the
possiblity of people posting the documentation errors to the net :-)).

-- 
Robert Bradbury
Oracle Corporation
(206) 364-1442                            hplabs!oracle!bradbury