acceptable way to program

[Chas Douglass]

[snip]

It is true. Most of the Java being written against relational
databases doesn't perform and doesn't scale well.

[snip]

Thats a pretty broad brush you're painting with. Do you have some numbers
on which your are basing this claim?

It also gives the impression that performance is the most important element
of software development, which is certainly not always true.

Chas Douglass

 

[Sudsy]

Chris Smith wrote:

There is undoubtedly some bad database programming being done by Java
programmers (and by C programmers, and especially by VB programmers,
etc.). Nevertheless, the use of Hibernate doesn't represent poor
database programming practice. What you should look for instead is ay
of the following indicators of poor use of Hibernate:

Stored procedures are, of course, not any part of relational theory at
all, so it's silly to complain that relational theory is being thrown
out. Use of Hibernate in no way contradicts relational theory.

Thanks for pointing out the obvious, Chris. That's not a snide comment,
BTW. I cringe when I see code which accesses a database in the worst
way possible. I strongly believe that you /need/ to understand how
databases work if you're going to program at the JDBC layer.
You don't need the same depth of knowledge if you're programming CMP
entity EJBs, although it wouldn't hurt.
I'm not suggesting that you need to be at the expert DBA level just to
create applications which access a database, but you do need to know
what's going on "under the covers" so you don't create queries which
perform an outer join and take 48 hours to process... ;-)
Don't laugh too hard: I've seen it done!
Your professional experience in this area makes your advice valuable.
I thank you for sharing your thoughts.

 

[Sudsy]

[snip]

It is true. Most of the Java being written against relational
databases doesn't perform and doesn't scale well.

[snip]

Thats a pretty broad brush you're painting with. Do you have some numbers
on which your are basing this claim?

It also gives the impression that performance is the most important element
of software development, which is certainly not always true.

Ah, but lack of performance becomes a very /big/ issue! People have
become accustomed to a certain level of responsiveness. Are you
willing to wait 30 seconds or more for a page to load on the www?
Of course not!
Based on my personal experience, there's a lot of lousy database
programming out there. The language doesn't matter, so we're probably
getting OT for a Java ng.
The "ad hoc" query support was probably one of the most counter-
productive "enhancements" seen in recent years. If you don't know
which columns in are table are indexed then you can create a very
"expensive" queries or updates. Even creating temporary indices in
order to resolve the request can be resource-intensive (disk and
CPU).
But if you do it right then it /does/ scale well. And if you've got
a sharp DBA willing to share their knowledge with the Java developers
then you've got a fighting chance to create a solution which is
efficient, responsive, and scalable.

Disclaimer: I'm not a DBA and never wanted to be; their specialized
knowledge can be invaluable, however.

 

[steve]

These people are nearly all morons and should be first against the wall
when the revolution comes.


Look into using Hibernate or Castor. They are much better solutions.
CMP EEJBs are kinda sorta OK, but not really. Until EJB 3.0 is
available, I still avoid them like the plague.

looked at hibernate, it seems to do mostly what I want, but it's another
thing I would have to learn.
Castor , didn't seem to fair too well , it get's a real slagging down in
various places on the net , seems some people are distinctly un-happy with
it.

steve

 

[Robert kebernet Cooper]

looked at hibernate, it seems to do mostly what I want, but it's another
thing I would have to learn.
Castor , didn't seem to fair too well , it get's a real slagging down in
various places on the net , seems some people are distinctly un-happy with
it.

steve

I have always been extremely pleased with Castor. Most of the
"slagging" it gets is in the "that's not JDO!" context. In terms of
utility and "work" I find it to be much more flexible than Hibernate in
many situations.

 

[DA Morgan]

[snip]

It is true. Most of the Java being written against relational
databases doesn't perform and doesn't scale well.

[snip]

Thats a pretty broad brush you're painting with. Do you have some numbers
on which your are basing this claim?

It also gives the impression that performance is the most important element
of software development, which is certainly not always true.

Chas Douglass

Very broad ... and I intentionally said "most" rather than "all" because
there is some very good Java being written too. My assessment comes from
two sources: The consulting work I have done for a number of Fortune 500
size corporations, and government agencies, in the last 5 years. Much of
my time has been spent teaching Java developers that the database is not
a bucket full of stuff. Their ignorance leads them too far too often
reinvent the wheel or insist on stupid stuff such as XML stored as XML
rather than being reconstituted on-the-fly. The other source of my broad
brushstroke is teaching at the University of Washington where I
regularly get students whose prior experience is Java and whose CIO or
IT manager has sent them to learn something about the database. They may
be very good at their primary job ... but their profound ignorance of
databases is amazing.

Addressing your second comment I would not say that performance and
scalability are the most important attributes of a program. But when
the database is capable of returning a result set in less than a second
and the Java developer getting the same result set uses a method that
takes 1-5 seconds there is a major problem and not just to the end-user.
Often management ends up purchasing far more expensive hardware to
compensate for bad design, bad implementation, and a lack of experience.

Let me give you some simple examples related to Oracle since that is
where this has been cross-posted. How many Java developers in your
organization know about the following?

EXPLAIN PLAN
TKPROF
TRACE ANALYZER
Bind Variables
Multiversion Read Consistency
Stored Outlines
Hints

And that is just the tip of the iceberg. The answer, undoubtedly, is a
very small number. And yet no serious Oracle DBA or developer would
consider doing much without one or all of them.

 

[Robert kebernet Cooper]

Morgan:

Often management ends up purchasing far more expensive hardware to
compensate for bad design, bad implementation, and a lack of

experience.

I think this is a problem that generally goes overstated. Bad design
isn't necessarily "slow" any more than good design is "fast". Good
design is extensible and maintainable. If it turns out to be slow, so
be it. Another server in the cluster or another gig of ram in a box is
MUCH cheaper than days of programmer time tweaking or weeks of
programmer time maintaining fast but cryptic designs.

Now, I have certainly made design mistakes from lack of experience that
lead to unmanagable performance situations -- overly fine grained
E-EJBs in the 1.1 line leaps to mind. However, given the option between
reasonable performance and "pretty" desings with and ORM-based system
built with an eye to the database vs a large and unweildy T-SQL/Java
integrated, stored procedure heavy mess, I will take the pretty code. I
won't understate the value of a good DBA, but the whole point of
N-tiers is we are driving business logic away from the DB and moving it
to languages and servers more geared to that work.

 

[Chas Douglass]

[snip]

It is true. Most of the Java being written against relational
databases doesn't perform and doesn't scale well.

[snip]

Thats a pretty broad brush you're painting with. Do you have some
numbers on which your are basing this claim?

It also gives the impression that performance is the most important
element of software development, which is certainly not always true.

Chas Douglass

Very broad ... and I intentionally said "most" rather than "all"
because there is some very good Java being written too. My assessment
comes from two sources: The consulting work I have done for a number
of Fortune 500 size corporations, and government agencies, in the last
5 years. Much of my time has been spent teaching Java developers that
the database is not a bucket full of stuff. Their ignorance leads them
too far too often reinvent the wheel or insist on stupid stuff such as
XML stored as XML rather than being reconstituted on-the-fly. The
other source of my broad brushstroke is teaching at the University of
Washington where I regularly get students whose prior experience is
Java and whose CIO or IT manager has sent them to learn something
about the database. They may be very good at their primary job ... but
their profound ignorance of databases is amazing.

Pardon my skepticism, but this could easily be a self-selecting sample,
could it not?

Aren't you hired as a consultant by companies that have problems in your
area of expertise (which appears to be DB's)? Aren't your students
coming to you for that expertise?

This appears to be similar to the classic case of the psychiatrist that
declared that "most people" had psychological problems -- based on his
experience that most of his patients were, well, crazy.

Of course, this doesn't mean you are wrong. But it does differ from my
experience -- which is also clearly anecdotal.

There are way too few controlled studies in life. To me, even an
assertion of "most" requires some verification of the methodology and
population.

Addressing your second comment I would not say that performance and
scalability are the most important attributes of a program. But when
the database is capable of returning a result set in less than a
second and the Java developer getting the same result set uses a
method that takes 1-5 seconds there is a major problem and not just to
the end-user. Often management ends up purchasing far more expensive
hardware to compensate for bad design, bad implementation, and a lack
of experience.

If this query occurs once every day, is it still a "major problem"? What
about once a week?

Let me give you some simple examples related to Oracle since that is
where this has been cross-posted. How many Java developers in your
organization know about the following?

EXPLAIN PLAN
TKPROF
TRACE ANALYZER
Bind Variables
Multiversion Read Consistency
Stored Outlines
Hints

And that is just the tip of the iceberg. The answer, undoubtedly, is a
very small number. And yet no serious Oracle DBA or developer would
consider doing much without one or all of them.

If your point is that any large development project would benefit from
expertise in the specific database to be used -- that is pretty hard to
disagree with.

If your point is that every Java programmer needs to be an expert in that
database -- I would definitely disagree. Hey, it might be nice, but this
is the real world.

(Should we drop comp.databases.oracle from followups? I'm not sure this
discussion is relevant there any longer. I'm reading this in c.l.j.p but
I don't know where you are reading it.)

Chas Douglass

 

[DA Morgan]

Pardon my skepticism, but this could easily be a self-selecting sample,
could it not?

Could be.

Aren't you hired as a consultant by companies that have problems in your
area of expertise (which appears to be DB's)? Aren't your students
coming to you for that expertise?

Absolutely. But the problems could be database tuning, the problems
could be bad SQL or PL/SQL code, the problems could related to network
or i/o bandwidth, or a multitude of other reasons: They rarely are.

So while you are possibly correct I do communicate regularly with
consultants throughout the US, Canada, and Western Europe and my
experience is not unique.

This appears to be similar to the classic case of the psychiatrist that
declared that "most people" had psychological problems -- based on his
experience that most of his patients were, well, crazy.

You've misstated the analogy. We have already agreed that most people
are crazy. Now we are diagnosing their specific disorder.

Of course, this doesn't mean you are wrong. But it does differ from my
experience -- which is also clearly anecdotal.

All opinions must be by definition as no company is going to lift its
kimono for publication to the outside world.

There are way too few controlled studies in life. To me, even an
assertion of "most" requires some verification of the methodology and
population.

If I were publishing in a peer reviewed journal I would agree. This
is the usenet and we are usually grateful if the post isn't rude,
obscene, or spam.

If this query occurs once every day, is it still a "major problem"? What
about once a week?

No such query. Objective research by Oracle and IBM have both shown that
the average database hosts, at most, a few hundred unique queries in the
lifetime of an application: Rarely are there unique queries except
during development.

If your point is that any large development project would benefit from
expertise in the specific database to be used -- that is pretty hard to
disagree with.

If your point is that every Java programmer needs to be an expert in that
database -- I would definitely disagree. Hey, it might be nice, but this
is the real world.

An expert no. But would you let your psychiatrist set a broken leg? They
are both MD's. Would you let your auto mechanic work on a Boeing 777 in
which you were about to fly to across the Atlantic? They are both
mechanics?

So while not an expert knowedgeable enough to be competent.

(Should we drop comp.databases.oracle from followups? I'm not sure this
discussion is relevant there any longer. I'm reading this in c.l.j.p but
I don't know where you are reading it.)

Chas Douglass

I am reading in the Oracle group but it should be noted that last year I
taught a JDeveloper class here at the U with one of the people that
helped write Hibernate. So I know my way, reasonably well, around Java too.

 

[Chas Douglass]

Chas Douglass wrote:

[snip stuff I agree with]

If I were publishing in a peer reviewed journal I would agree. This
is the usenet and we are usually grateful if the post isn't rude,
obscene, or spam.

Touche.


No such query. Objective research by Oracle and IBM have both shown
that the average database hosts, at most, a few hundred unique queries
in the lifetime of an application: Rarely are there unique queries
except during development.

I see your point, and even though my comment was somewhat hyperbolic, it
is still not out of the question for any single query to be both in-the-
set-of-a-few-hundred-unique-queries and also only-run-once-a-day
(backup?).

An expert no. But would you let your psychiatrist set a broken leg?
They are both MD's. Would you let your auto mechanic work on a Boeing
777 in which you were about to fly to across the Atlantic? They are
both mechanics?

So while not an expert knowedgeable enough to be competent.

I think your analogy works against you. Do I care if my family physician
can read the MRI of my head and spot a brain tumor, as long as an expert
does read it?

Do I care if any particular Java programmer is an Oracle expert, as long
as I have an Oracle DBA on board with appropriate design/review
responsibilities?

Certainly, my physician must be broadly trained enough to know to request
an MRI and an expert reading. And any Java programmer should be trained
broadly enough to know when to ask their DBA for help.

I would argue that having a problem domain expert (for instance, an
Oracle DBA) is not just a great idea, but a requirement for any non-
trivial database program.

I would also argue that, in the real world, we're not going to hire a
whole team of Java/Oracle experts.

I don't even think it would be a good idea. If I decide to switch from
Oracle to DB2, do I want to replace one expert, or my whole team?

I am reading in the Oracle group but it should be noted that last year
I taught a JDeveloper class here at the U with one of the people that
helped write Hibernate. So I know my way, reasonably well, around Java
too.

I apologize if I, in any way, implied that your knowledge of Java (or
anything else, for that matter) was at issue.

Chas Douglass

 

[DA Morgan]

I see your point, and even though my comment was somewhat hyperbolic, it
is still not out of the question for any single query to be both in-the-
set-of-a-few-hundred-unique-queries and also only-run-once-a-day
(backup?).

Backup isn't a query with any commercial relational database. And while
there are queries that may be run daily or quarterly they are the rare
exception in a database system and not likely to have much impact. When
I say likely one should keep in mind that they are also likely to be
written in Crsytal Reports or Cognos and not have Java front-end.

I think your analogy works against you. Do I care if my family physician
can read the MRI of my head and spot a brain tumor, as long as an expert
does read it?

No I don't care whether my family physician can read an MRI. Because
when I go to get an MRI there is a radiologist that is an expert. And
that is exactly the same as what I expect when someone attaches to a
database and runs a DML statement (insert, update, delete, select).
The Java programmer that hits a database and is as clueless as my
family physician is precisely the problem.

So how does my analogy work against me?

Do I care if any particular Java programmer is an Oracle expert, as long
as I have an Oracle DBA on board with appropriate design/review
responsibilities?

The vast majority of Oracle DBAs couldn't read curly braces much less
Java. They may be reviewing your design but they are not reviewing your
code. And in many organizations there are turf and religious wars that
weigh heavily against even the knowlegeable DBA insisting that the
PL/SQL developers write APIs for the Java folk.

Certainly, my physician must be broadly trained enough to know to request
an MRI and an expert reading. And any Java programmer should be trained
broadly enough to know when to ask their DBA for help.

Once again you assume a level of DBA expertise that from my perspective
does not exist.

Which is not to say that your specific DBA can't read Java but lets
find out how much they know about tuning your code. Ask your DBA the
following question.

What is DBMS_PROFILER and when was the last time you ran it?

My guess is that you get a completely blank stare. But in case you
want a bit of background before you ask the question:

http://download-west.oracle.com/docs/cd/B14117_01/appdev.101/b10802/d_profil.htm#ARPLS039

I would argue that having a problem domain expert (for instance, an
Oracle DBA) is not just a great idea, but a requirement for any non-
trivial database program.

I agree but it doesn't change the nature of the problem as stated above.

I would also argue that, in the real world, we're not going to hire a
whole team of Java/Oracle experts.

In most cases I'd be pleased if I saw just one.
Of course I'd also probably not get the jobs as they wouldn't need me. ;-)

I apologize if I, in any way, implied that your knowledge of Java (or
anything else, for that matter) was at issue.

I didn't take it that way. It was just informational. No apology required.

 

[Haximus]

does anyone have any thoughts how to accomplish this task.

Why not just use BC4J/ADF and JClient? I don't think you're going to find a
much easier way to build Java clients for Oracle, and your app doesn't sound
like a complex model that requires OO. As a side benefit you will be
keeping your interoperability options open, becasue if you store data as
java objects... guess what you are limited to on the client-side and/or
middle-tiers!!!

 

[Haximus]

It is true. Most of the Java being written against relational databases
doesn't perform and doesn't scale well. The saving grace for all of
those Java geniuses is that they can blame it on the web and 99% of IT
management is too clueless to know better.

That is pure opinion but you're welcome to it. I'm not sure why relational
purists are so biased against Java, but I can't think of a single
programming language that has increased the productivity of programmers more
than Java. Personally I prefer Java Stored Procedures to PL/SQL because
they are far quicker to develop and easier to debug, not too mention the
performance is comparable and sometimes superior when using the native
libraries. I can't understand why someone would choose clunky old PL/SQL
unless they are stuck in "the old days."

 

[Mark C. Stock]

That is pure opinion but you're welcome to it. I'm not sure why
relational purists are so biased against Java, but I can't think of a
single programming language that has increased the productivity of
programmers more than Java. Personally I prefer Java Stored Procedures to
PL/SQL because they are far quicker to develop and easier to debug, not
too mention the performance is comparable and sometimes superior when
using the native libraries. I can't understand why someone would choose
clunky old PL/SQL unless they are stuck in "the old days."

i've not programmed much in Java and OO (yet), but i'm well-qualified as a
PL/SQL dinosaur.

however, i'm also well-qualified to have observed a tremendous decrease in
productivity and an increase in complexity concurrent with the rise in
popularity of Java and OO.

i believe the current state of disorganization in oracle database and app
server installation, configuration, and documentation is a symptom of the
mentality that has accompanied the rise of Java, OO, and web technologies,
of course complicated by oracle's traditional way of doing business.

i don't dismiss Java and OO, i acknowledge their likely superiority for
certain scenarios. but, like daniel, i have seen a good amount of myopic
usage of the technology. my general experience in the field is to see it
viewed as a magic potion that can solve any problem better than anything
else, but often (yet not always) end up gumming things up by those who don't
acknowledge the need to understand and use relational technology correctly.

++ pl/sqlasaurus mcs

 

[Haximus]

i've not programmed much in Java and OO (yet), but i'm well-qualified as a
PL/SQL dinosaur.

however, i'm also well-qualified to have observed a tremendous decrease in
productivity and an increase in complexity concurrent with the rise in
popularity of Java and OO.

i believe the current state of disorganization in oracle database and app
server installation, configuration, and documentation is a symptom of the
mentality that has accompanied the rise of Java, OO, and web technologies,
of course complicated by oracle's traditional way of doing business.

i don't dismiss Java and OO, i acknowledge their likely superiority for
certain scenarios. but, like daniel, i have seen a good amount of myopic
usage of the technology. my general experience in the field is to see it
viewed as a magic potion that can solve any problem better than anything
else, but often (yet not always) end up gumming things up by those who
don't acknowledge the need to understand and use relational technology
correctly.

There's no doubt trying to wrap OO around a relational database is going to
have "issues," but there's just no getting around the fact that you can't
build truly sophisticated client front-ends with PL/SQL. My first Oracle
experience was with Forms 9i, and from the literature and my research it was
touted as the "RAD" tool to use. I soon discovered that I did not like
PL/SQL very much and development was not at all rapid for my purposes, in
fact many of the language features available on the server-side were not
compatible with the client-side (for example associative arrays, something
Java programmers take for granted), and when I soon realized that Forms 9i
was just a Java applet and wrapper for client-side PL/SQL, I switched to
JDeveloper and haven't looked back. One of the benefits I find that works
for me is the ability to develop/debug/test Java code completely
client-side, then move it to stored procedures with a few minor changes, or
move the code to a middle-tier... or wherever... the portability and
flexibility is what I like. What people seem to balk at is the bit of work
it takes converting back and forth between Java types and PL/SQL types...
not a big issue really. A someone who has tried both PL/SQL and Java... I
can honestly say I will not use PL/SQL unless I absolutely have to, but I
will acknowledge that Java can create huge messes in the wrong hands.