One person that DBAs can use as an "ally" is the network guy. With
stored procedures, more of the processing is handled locally in the DB
server(s). In large projects it might justify to create a simple
prototype of both kinds of app (with and without PL/SQL) and test them
using a network sniffer. Yes, performance diffs won't probably be seen
in a small test, but you can measure the amount of data (# of packets)
transmitted from the server to a "client" (might be an app server
here). There are commercial tools and open source ones
(www.ethereal.com) that you can use just to measure the data (and those
SQL*Net stats can also be used).
On Jun 3, 2004, at 8:53 AM, Daniel Fink wrote:
...
I just had a conversation with a developer about the same kind of issue. After a long discussion, I recommended that they not use stored procedures and kept the data loading/validation in the app layer using java. In this case, they needed to get the app through the development process quickly, performance is not an option (at least at this point...I'm guessing this will change) and the team knows java, not pl/sql. He is well aware of the performance
problems.
Cynically, Daniel Fink
---------------------------------------------------------------- Please see the official ORACLE-L FAQ: http://www.orafaq.com ---------------------------------------------------------------- To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx put 'unsubscribe' in the subject line. -- Archives are at //www.freelists.org/archives/oracle-l/ FAQ is at //www.freelists.org/help/fom-serve/cache/1.html -----------------------------------------------------------------
