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

Well, writing SQL in Java is not actually that hard if you use SQLJ (which is supported by Oracle as well) - it hides all the complexity of JDBC and allows you to write Java code with embedded SQL almost the same way you do it in PL/SQL. For example, to select something:

String var;
#sql {SELECT something INTO :var FROM some_table WHERE condition}; ...

Any DML is supported. You can also call stored procedures, emulate cursor loops with iterators, etc. SQLJ translator transparently processes these 'macros' into actual JDBC calls.

As of sending mail from Oracle - starting with 8i Release 2 (8.1.6) Oracle supplies UTL_SMTP for this purpose. And we have encapsulated and extended it with our PSP_Mail product (you can get trial version and docs at http://www.dpsp-yes.com)

--
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.


"Luis Cabral" <luiscabral99_at_ig.com.br> wrote in message
news:c9ff1799.0202160409.15944c0f_at_posting.google.com...


> Hi

>

> 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