jbeard@quintus.UUCP (Jeff Beard) (11/21/89)
Embedded SQL is fine for cases were aprori (sp?) knowledge of the request(s)
is available. A browser or user front-end for ad hoc queries is NOT such an
animal and therefore the embedded SQL approach is almost useless.
For our AI interface, not only do we access any table (within authority
constraints) but also any projection of any join subset thereof. As
an attribute name may not be used as an SQL variable, the embedded approach
will never be the functional equivalent of SOME OCI operations.
For example, let EMP be a table containing four attributes, EMPNO,NAME,DEPT,MGR.
To use embedded SQL to access one attribute at a time, four separate queries
are required ( select ATTNAME from EMP; ). To cover all permutations requires
!4 or 24 unique queries. The OCI functions {osql3,odefin,obndrv}() allow
one to specify exactly the attributes required by the user and avoid the
simplistic SELECT * from Table approach, thus saving large IPC transfers and
poor DBMS performance. It also allows correct table joins ( you can't get
a decent join using ( select * from T1,T2 ).
Some other vendors like to say "...then why not try <My product name> ...".
They too fall into this pit with their software. Worse yet, at least
one un-named vendor has embedded SQL but without the dynamic SQL feature.
Embedded SQL is just fine where the user front-end collects sufficient
information to invoke a given transaction. The mappings and implementation
are straight forward. Ad hoc browsers require more flexibility than currently
present in embedded SQL implementations.
===
Opinions are the possession of the speaker and to assert otherwise
is plagiarism.
Jeff Beard, Quintus Computer Systems, Inc.
e-mail ...!amdahl!sun!quintus!jbeard
phone (415) 965-7700