Re: Why use Java Stored Procedures....

From: Joe Weinstein <joeNOSPAM_at_bea.com>
Date: Wed, 01 Mar 2006 16:36:27 -0800
Message-ID: <44063da2@news.bea.com>

Bob Jones wrote:

> "HansF" <News.Hans_at_telus.net> wrote in message 
> news:pan.2006.03.01.22.08.14.356624_at_telus.net...
> 

>>On Wed, 01 Mar 2006 19:09:16 +0000, Gerry Atric wrote:
>>
>>
>>>Miggins wrote:
>>>
>>>
>>>>OK short question but probably not a quick answer....anyone give me the
>>>>pros and cons of using Java for my stored proedures instead of PLSQL.
>>>
>>>
>>>
>>>CON: PL/SQL is 100% Oracle-centric while Java is not. If you ever want
>>>to
>>>migrate your apps away from Oracle for some reason, keep in mind that all
>>>of your PL/SQL code will have to be ported too. My personal rule of
>>>thumb,
>>>anything I develop in PL/SQL I do with the assumption that it will never
>>>be
>>>ported in the future.
>>
>>If you copy Oracle-optimized Java stored procedures to other databases
>>without thinking, the procedure is likely to have performance, locking
>>or concurrency problems.
>>
>>If you did not take advantage of Oracle capabilities, you may be causing
>>performance issues that can easily result in the need to purchase
>>additional equipment and additional Oracle licenses. Thus creating the
>>perception that Oracle is expensive, even though the reason for the
>>expense is laziness or simple misuse of the environment for the sake of
>>'independence'.
>>
>>
>>Therefore, my belief is that using Java - if written properly (cost
>>effectively) - must be ported in the same sense as PL/SQL ... with
>>thought.
>>

> 
> 
> Would you rather have a Java programmer migrating Java stored procedures to 
> a different database or have a PL/SQL programmer migrating PL/SQL stored 
> procedures to a foreign language for a different database? 

To the extent that the stored procedure have anything to do with actual data access, I would prefer that the procedures be translated (at the level possible) to the new DBMS's native SQL language. The warning I want to emphasize here is that Java in both DBMSes does zero-nothing-nada to overcome the structural differences in capability, locking and procedural code that are fundamental to getting quality function out of a DBMS engine. First and foremost, I want deep and specific DBMS expertise if I want a well-running application with that DBMS. As far as DBMS internals are concerned, Java is like teaching Esperanto to the Palestinians and Israelis. It won't help them share much until they're already going to each other's parties...
MHO,
Joe Weinstein at BEA Systems Received on Wed Mar 01 2006 - 18:36:27 CST