Re: What's the best alternative to this pl/sql ?

Karsten Farrell wrote:

> no-spam_at_no-spam.com said...
> >
> > "Billy Verreynne" <vslabs_at_onwe.co.za> wrote in message
> > news:b3kvp1$d51$1_at_ctb-nnrp2.saix.net...
> > > Gabriel Gonzalez wrote:
> > >
> > > > Otherwise, save yourself some time and create the SQL on the client.
> > Make
> > > > sure you use bind variables/parameters and prepared statements so that
> > at
> > > > least the parsed queries remain in the cache to speed up performance of
> > > > repeat SQL statements. It should give you a speed boost anyway.
> > >
> > > Sorry, I don't understand this. It sounds like bollocks to me.
> > >
> > > How can you say that shifting the code from PL/SQL to something like C++
> > or
> > > Delphi or Perl or whatever, will boost speed?
> >
> > As compared to not using prepared statements, it will... Maybe I dod not
> > make that clear enough. Comparison was uprepared vs prepared client
> > queries, not client vs server queries.
> >
> >
>
> You are correct if you mean using Java's PreparedStatement as opposed to
> its Statement ... because a PreparedStatement gives you bind variables.
> However, in the web world, you can't always use PreparedStatements
> because (at least in some cases) you have to maintain a connection.
> Sometimes connecting for each PreparedStatement takes longer than the
> hard parse required by a Statement. You have to test in your particular
> environment to see which is more efficient. Do you want to spend your
> time in the middle tier or the backend tier?
> --
> /Karsten
> DBA > retired > DBA

If the source of the SQL is some front-end I'd advise against putting any SQL there at all ... compiled, prepared, or otherwise. Passing SQL statements across a wire is not an efficient use of resources.

Daniel Morgan Received on Thu Feb 27 2003 - 16:30:53 CST