Re: database operations from Java or PL/SQL packages?

[Quoted] [Quoted] Personally I wouldn't go for server-side Java unless absolutely unavoidable. The order of preference of tools/languages to do something in Oracle is:

SQL
PL/SQL
Java
external C
you probably don't need to do it :)

(shamelessly stolen from Thomas Kyte - recommended reading btw). As of client-side - think of it as of presentation layer of your application. You should try to move as much of the business logic into Oracle as possible. Client should only provide data entry and data display controls. This way you are ultimately unlimited with client platform selection - you will be able to create clients for all the diverse platforms (be it PCs, terminals, PDAs or whatever) with equal ease. And Oracle will handle the data and business logic. It is generally a waste of resources to treat Oracle merely as a data storage and retrieval facility (or as a black box) and offload data processing to the client.

My 2 cents.

--
Vladimir Zakharychev (bob_at_dpsp-yes.com)                http://www.dpsp-yes.com
Dynamic PSP(tm) - the first true RAD toolkit for Oracle-based internet applications.
All opinions are mine and do not necessarily go in line with those of my employer.


"obakesan" <pellicle_at_hotmail.com> wrote in message
news:9baa2b9f.0202142234.2e9b7fa0_at_posting.google.com...


> HiYa

>

> I am a little new to Java, and I am not sure what is the best way to


> access the database from our applications.

>

> On the one hand we can code all the access (selects, updates, inserts)

> into the Java, but I am not sure if this is making the best use of

> resources. In the past I used Packages from both Pro*C and Forms to

> seperate database table knowledge from the application ...

>

> Is this same thinking equally applicable to Java?? I am a little

> unclear on this as it seems that Java procedures can be placed into

> the database, just like PL/SQL procedures can.

>

> But this is different to packages I am a little unsure which is the

> best for performance and maintainability at this point ....

>

> I would be pleased if someone has some suggestions, or some pointers

> on further reading in this area.

>

> Thanks folks