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

From: Luis Cabral <luiscabral99_at_ig.com.br>
Date: 16 Feb 2002 04:09:22 -0800
Message-ID: <c9ff1799.0202160409.15944c0f_at_posting.google.com>


Hi

[Quoted] I do agree with you, but in the new "trend" of technologies, like J2EE (that is strongly supported by Oracle), the database is supposed to be just a "data storage and retrieval facility", as all the business logic and validation must reside in the "entity beans" (at least, that's how I understood...) I've known people who said "you never should use stored procedures if you want to build a true J2EE app".

I do think it is a waste using Oracle like this. For some app this structure may be interesting, but not for *all*, as it is common to hear.

And I can't understand why someone should use Java instead of PL/SQL in the database. For just an example, if you want to SELECT a value from a table, in PL/SQL you just do SELECT...INTO... (or use a explicit cursor). In Java, you must 1-open a connection to the db 2-create a statement 3-execute the statement 4-access the resultset through some fancy API. For a insert/update it is even worse. I don't think it is productive...

Of course, if you want to send email or something like that Java is useful (though I think Oracle could have improved PL/SQL to do that).

Luis Cabral

"Vladimir M. Zakharychev" <bob_at_dpsp-yes.com> wrote in message news:<a4jjj6$f5h$1_at_babylon.agtel.net>...
> 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
Received on Sat Feb 16 2002 - 13:09:22 CET

Original text of this message