Re: PLSQL versus OCI versus JDBC

It's always faster to run a stored procedure on the server side, rather than doing the same task via a client side app. The network overhead (Net8 + TCPIP stack overhead) saved alone is worth the consideration. Even if you run the client app on the same physical machine as the server, the best you can do is IPC which is still slower than running a stored procedure *in process* with the server.

I agree with you that OO is a good option in order to make the code more easily maintainable and reuseable. In this case, you should seriously consider using a Java stored procedure on the Oracle server.

Cheers,
Dave

Menelaos Perdikeas wrote:
> Hi
>
> I 've got to built an application that would "synchronize" between two
> different database schemas (different structurally but semantically
> equivalent so that a mapping can be defined). Anyway, the logic for
> this mapping or synchronization (which will probably be run once a day
> and involve 1 millions rows) is quite involved and so I would rather
> built a client application in C++ using OCI or in Java using JDBCs to
> mediate between the two instances than rely on the loosely typed
> (according to my taste) PL-SQL. The code will be much more readable,
> maintainable and elegant (in my opionion) in a proper language than in
> PL-SQL. Anyway, thats not what I want to ask. My question is : would
> one expect the C++ or Java implementation to operate in a greatly
> reduced speed compared to PL-SQL ? Being an OO fan and nursing an
> inherent dislike for "languages" like PL-SQL, I would opt for C++ or
> Java even if it were 5 times slower. Do you feel this might be the
> case? ( I am only assuming that PL-SQL would be faster in this
> scenario since the data will not need to make the trip to a client PC
> and then back to the second server but the migration of data will take
> place entirely between the two servers). Any hints ?
>
> Thanks,
> Menelaos Perdikeas.
Received on Wed Jun 18 2003 - 14:28:56 CDT