Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!ucbvax!agate!hughes@math.Berkeley.EDU
From: hughes@math.Berkeley.EDU (Eric Hughes)
Newsgroups: comp.databases
Subject: Re: Do you like your UNIX RDBMS?
Message-ID: <25059@agate.BERKELEY.EDU>
Date: 31 May 89 02:35:28 GMT
References: <9703@dasys1.UUCP>
Sender: usenet@agate.BERKELEY.EDU
Reply-To: hughes@math.Berkeley.EDU (Eric Hughes)
Organization: UCB Mathematics Department
Lines: 43
In-reply-to: emuleomo@yes.rutgers.edu (Emuleomo)

In article <May.30.18.32.22.1989.943@yes.rutgers.edu>, emuleomo@yes (Emuleomo) writes:
>The problem with Embedded SQL is that is super lousy for browsing thru' a 
>database.
   [example deleted]
   [Summary: an embedded query is completely processed before any access]
>						   (I think this goes to show
>that we need 2 simultaneous database models. Relational and Network!)
   [other example about lack of ability to go backwards deleted]

The answer is not to keep more than more than one data model around.
The problem lies in the implementation, not the idea.

First, sometimes it is the case that the whole query must be processed
before any viewing takes place.  This happens under many conditions.
For example, when no physical index exists which corresponds to the
sort order of the requested table, the whole table must be constructed
and then sorted.  For example, when a quantifier which maps to a
relational DIVISION operation is present, generally at least one
operand must be constructed as a temporary file.

If the user is not the sole user of the database, there may be a
problem with updating (add/change/delete) taking place some member
table while the SQL cursor is active.  Sometimes this doesn't matter,
sometimes it is very important.  I do not know if any commercial
system allows one to specify such a parameter.

But, if none of the above are relevant, then the optimizer for the
runtime SQL is cheap and lowly.  'SELECT *' on a database table should
pull up the first record quickly, or the vendor has not supplied a
very good implementation.  A common case for selection (at least in
what I do) is where the order of the constructed table is derived from
the physical index of a record, and all other records are joined to
it by foreign keys for which physical indices are available.  In
this case the obvious optimization is to read the root record, then
read in any child record by its foreign key, and so one until all
records have been joined.  

I am not familiar enough with embedded SQL to say whether any
commercial products do this.  From what the previous poster's
experience shows, he does not seem to have come across any such.

Eric Hughes
hughes@math.berkeley.edu   ucbvax!math!hughes