RE: Java vs. Perl

  • From: "Cary Millsap" <cary.millsap@xxxxxxxxxx>
  • To: <oracle-l@xxxxxxxxxxxxx>
  • Date: Fri, 2 Apr 2004 10:31:45 -0600

Thanks Dennis. 

As you know, I work outward into the application from the trace file
that tells me where a system is spending its time. One really common
place for applications to spend users' time is in the communications
round trips with the database. Every round-trip is, of course, motivated
by the application source code somehow. So this typically motivates me
to study the application's interface to the database (the db driver) and
how the application code makes calls to it (whether the calls are inside
loops, and things like that). I think you're right on target with the
PreparedStatement quest, and in general learning the details of how the
application interfaces with the database.

If you're unlucky enough to live in one of these worlds that attempts
pure object-oriented development (for example, every table has an OO
Java access method, and joins are done in Java instead of in Oracle),
then your performance is probably going to be catastrophic until either
you conquer enormous political summits or you find a new place to work.
(Of course, if you find a new place to work, the performance problem
doesn't go away, it's just not /your/ performance problem anymore ;) ).
But you can't even attempt to climb a political hill like the one to gut
and rewrite an application unless you know enough about the application
development language to speak in the application design (or re-design)
meetings.


Cary Millsap
Hotsos Enterprises, Ltd.
http://www.hotsos.com
* Nullius in verba *

Upcoming events:
- Performance Diagnosis 101: 4/6 Seattle, 5/7 Dallas, 5/18 New Jersey
- SQL Optimization 101: 4/19 Denver, 5/3 Boston, 5/24 San Diego
- Hotsos Symposium 2005: March 6-10 Dallas
- Visit www.hotsos.com for schedule details...


-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of DENNIS WILLIAMS
Sent: Friday, April 02, 2004 10:14 AM
To: 'oracle-l@xxxxxxxxxxxxx'
Subject: RE: Java vs. Perl

Cary
   Well said, as always. Can you pinpoint any parts of Java that are
good
for a DBA to concentrate on? I've learned just enough OOP to understand
that
languages like Java don't always lend themselves to clear transaction
boundaries. Mostly I've used that as a well of empathy so I can look
sympathetic and nod and agree and then say "yeah but you've got to
figure it
out somehow." 
   I push the Java developers to use PreparedStatement. This causes Java
to
use bind variables. If I tell a Java developer to use bind variables,
they
look blankly, but they do understand PreparedStatement, or can at least
go
back and look it up in a book. Aside from the benefits in Oracle, it
also
defeats the SQL Injection hacking technique.
   I would gratefully appreciate any other points you would care to
share.

Dennis Williams
DBA
Lifetouch, Inc.
dwilliams@xxxxxxxxxxxxx 

-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx]On Behalf Of Cary Millsap
Sent: Friday, April 02, 2004 9:51 AM
To: oracle-l@xxxxxxxxxxxxx
Subject: RE: Java vs. Perl


The only reason I would recommend for a DBA to learn Java is if that's
what your applications are written in. If you have any performance
responsibilities, you MUST know something about the language your apps
are written in. Substitute whatever your app is written in for "Java" in
this paragraph (PHP, COBOL, C++, C#, Visual Basic, ...it doesn't matter;
whatever your app is written in). This, by the way, is why you MUST
understand SQL and probably also PL/SQL (if you're lucky); it's part of
what your apps are written in.

Perl is another story. Maybe your app is written in Perl, but probably
not. Even so, Perl, Python, ksh, SQL, PL/SQL, and others are tools that
a DBA might use to create new tools that help you do your job more
effectively. There's probably someone out there who writes DBA scripts
in Java, but whoever you are, I don't envy you. :)


Cary Millsap
Hotsos Enterprises, Ltd.
http://www.hotsos.com
* Nullius in verba *

Upcoming events:
- Performance Diagnosis 101: 4/6 Seattle, 5/7 Dallas, 5/18 New Jersey
- SQL Optimization 101: 4/19 Denver, 5/3 Boston, 5/24 San Diego
- Hotsos Symposium 2005: March 6-10 Dallas
- Visit www.hotsos.com for schedule details...


-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of David Lee
Sent: Friday, April 02, 2004 9:37 AM
To: oracle-l@xxxxxxxxxxxxx
Subject: RE: Java vs. Perl

There are many reasons to use one tool over another.  For me and
my company, perl offers faster development time.  What it boils
down to, both tools allow you to connect to the Database so anything
that can execute SQL or pl/sql is fine.

In the past, executing the same business logic with medium to big amount
of data (100k+ records) is faster in perl than java.  Unfortunately I=20
don't have any statistics to back to support this.  Anyone?

The java developers that I know of, uses ODBC or OCI, to communicate =
from
the java application server (ATG) to 8i.  I don't know of anyone
using=20
java and communicating to Oracle's API. =20

- David Lee
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx]On Behalf Of Juan Cachito Reyes
Pacheco
Sent: Friday, April 02, 2004 10:04 AM
To: oracle-l@xxxxxxxxxxxxx
Subject: Java vs. Perl


Hi, please there is another reason than simple know perl, to use perl
instead of Java.
I always heard Java had more advantages than perl, including the fact =
that
Oracle include it in the database.

Now you are talking as much about perl, and I am thinking to study java,
=
I
am asking which is
best. for most purpouses.


Thanks :)

Juan Carlos Reyes Pacheco
OCP
Database 9.2 Standard Edition


----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to:  oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to:  oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------

----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to:  oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to:  oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------

----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to:  oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------

Other related posts: