| See note 302 where I have described PL/SQL. It is in beta now.
PL/SQL will offer functionality similar to BLR request handles.
For example, if an Rdb program submits four different database
activities (insert, 2-queries, update, for example), Rdb will
"remember" the four database "requests" and assign an identifier
(handle) to each one. When your program loops and does the same
activity a second time (insert, for example), Rdb remembers this
request (because it knows the handle) and simply executes the request
instead of creating it all over again. One problem with Rdb is that,
for the most part, the database requests go away when your program
unbinds from the database.
From what I can tell based on discussions with a couple of Oracle dbas,
the parsing of Oracle SQL statements is quite CPU intensive and
contributes greatly to poor performance. It is not exactly like dynamic
SQL but pretty close. One of the primary reasons for PL/SQL is to
eliminate the SQL parsing performance.
The other reason for PL/SQL is to allow these routines to be stored
in their compiled state in a database and to have the application
simply call them by name. This would eliminate the problem of having
to code the same SQL routines over and over in SQL*forms or in your
application program. On the same hand, in a remote or distributed
database situation, the local program could "call" a remote PL/SQL routine
in the remote database thus avoiding the need to move data across
the network to perform the query.
So, as you can see, PL/SQL will contain pieces of Rdb request handles,
SQL services, and SQL module language and, according to the two dba's I
know, will be great ..... IF ... Oracle ever gets it done.
-- gerry
|