Hi Shazin,
In addition to what Dag said, I would say this:
1) Writing your procedural code in Java (rather than SQL/PSM) makes it
possible to factor your code so that pieces (like integrity and
validation logic) can be shared across all tiers of your application. As
you tune your application, you can move that code up and down the
call-stack to the tier where you get the best performance. The same code
can run in your client, in the middle tier, and in the database itself.
2) Writing your procedural code in Java (rather than SQL/PSM) gives you
access to a large ecosystem of development tools, including debuggers.
You can debug your application in embedded mode--here the same debugger
is responsible for your procedural code and your client code.
3) Writing your procedural code in Java gives your database procedures
access to all the advantages of the Java language itself, including:
a) a large ecosystem of off-the shelf freeware
b) compilers which do half of your debugging for you
c) powerful exception handling
The "Java in the Database" presentation (from Apache Con USA 2006) may
be useful: http://db.apache.org/derby/papers/ApacheCon.html
Hope this helps,
-Rick
Shazin Sadakath wrote:
Hi,
Recently I have been going through the Wiki
http://wiki.apache.org/db-derby/DerbySQLroutines
And it states I quote
" The advantage of Java procedures is that the same procedure will run
on any database that supports the standard, such as Derby, IBM's DB2
and Oracle"
Apart from this single advantage there aren't much to registering Java
Procedures in derby database, so why doesn't derby database support
standard SQL Stored Procedures (Such as Oracle PL/SQL..) without
registering public static void methods as Stored Procedure. Any
particular reason to this?
Thanks in advance,
Shazin
