acceptable way to program

#21

steve wrote:

Quote:

On Sun, 2 Jan 2005 18:00:15 +0800, Robert kebernet Cooper wrote
(in article <1104660015.626693.96680 (AT) z14g2000cwz (DOT) googlegroups.com>):

steve wrote:
Hi,

Recently I have been looking at the various ways people are
implementing,
interaction between java & oracle databases.

I have seen people Serializing java objects , such as purchase
orders
orders, customer records etc , then sticking the "object" into am
oracle blob
column.

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

I'm looking to implement a java front end, (oracle back end),
system
,that
allows a product , to be inspected by an inspection team , and
comments/
photographic record kept.

using an "object approach" would make it very simple, but the size
of
the
resulting object could be very large.

does anyone have any thoughts how to accomplish this task.

steve

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

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.

#22

Chas Douglass wrote:

Quote:

DA Morgan <damorgan@x.washington.edu> wrote in
news:41d8219f$1_1 (AT) 127 (DOT) 0.0.1:

[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.
--
Daniel A. Morgan
University of Washington
damorgan@x.washington.edu
(replace 'x' with 'u' to respond)

#23

DA Morgan <damorgan@x.washington.edu> wrote in
news:41d87f2e$1_1 (AT) 127 (DOT) 0.0.1:

Quote:

Chas Douglass wrote:
DA Morgan <damorgan@x.washington.edu> wrote in
news:41d8219f$1_1 (AT) 127 (DOT) 0.0.1:

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

Quote:

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?

Quote:

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

#24

Chas Douglass wrote:

Quote:

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

Could be.

Quote:

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.

Quote:

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.

Quote:

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.

Quote:

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.

Quote:

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?

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.

Quote:

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.

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.

Quote:

(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.
--
Daniel A. Morgan
University of Washington
damorgan@x.washington.edu
(replace 'x' with 'u' to respond)

#25

DA Morgan <damorgan@x.washington.edu> wrote in
news:41d9a797$1_3 (AT) 127 (DOT) 0.0.1:

Quote:

Chas Douglass wrote:

[snip stuff I agree with]

Quote:

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.

Touche.

Quote:

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?

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

Quote:

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.

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?

Quote:

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

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

Chas Douglass

#26

Chas Douglass wrote:

Quote:

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?

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

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.

Quote:

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?

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?

Quote:

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.

Quote:

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...l.htm#ARPLS039

Quote:

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.

Quote:

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

Quote:

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

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.

Quote:

Chas Douglass

--
Daniel A. Morgan
University of Washington
damorgan@x.washington.edu
(replace 'x' with 'u' to respond)

#27

"steve" <me (AT) me (DOT) com> wrote

<snip>

Quote:

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

#28

"DA Morgan" <damorgan@x.washington.edu> wrote

Quote:

fishfry wrote:
In article <IhjBd.5746$6i.1873 (AT) bignews6 (DOT) bellsouth.net>,
"Tom Dyess" <tdyess (AT) dysr (DOT) com> wrote:

Yes, I would agree with the relational database. ORDB are mainly hype and
usually promoted by coders that have never had to write a report or mine
data effectively.

Is this really true? I'm an experienced database programmer learning the
Java/OO way of doing things and I'm puzzled that people use Hibernate and
similar tools to define objects, with the database serving as just a
passive serialization mechanism with no thought to database theory. How
can this possibly work in real life? Also I've been told that stored
procedures are not supported by Hibernate, is that true? How can it be
that 20 years of relational theory seems to be getting thrown out
overnight? Or am I just misinformed?

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

#29

"Haximus" <e@t.me> wrote

Quote:

"DA Morgan" <damorgan@x.washington.edu> wrote in message
news:41d8219f$1_1 (AT) 127 (DOT) 0.0.1...
fishfry wrote:
In article <IhjBd.5746$6i.1873 (AT) bignews6 (DOT) bellsouth.net>,
"Tom Dyess" <tdyess (AT) dysr (DOT) com> wrote:

Yes, I would agree with the relational database. ORDB are mainly hype
and usually promoted by coders that have never had to write a report or
mine data effectively.

Is this really true? I'm an experienced database programmer learning the
Java/OO way of doing things and I'm puzzled that people use Hibernate
and similar tools to define objects, with the database serving as just a
passive serialization mechanism with no thought to database theory. How
can this possibly work in real life? Also I've been told that stored
procedures are not supported by Hibernate, is that true? How can it be
that 20 years of relational theory seems to be getting thrown out
overnight? Or am I just misinformed?

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

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

#30

"Mark C. Stock" <mcstockX@Xenquery .com> wrote

Quote:

"Haximus" <e@t.me> wrote

"DA Morgan" <damorgan@x.washington.edu> wrote in message
news:41d8219f$1_1 (AT) 127 (DOT) 0.0.1...
fishfry wrote:
In article <IhjBd.5746$6i.1873 (AT) bignews6 (DOT) bellsouth.net>,
"Tom Dyess" <tdyess (AT) dysr (DOT) com> wrote:

Yes, I would agree with the relational database. ORDB are mainly hype
and usually promoted by coders that have never had to write a report or
mine data effectively.

Is this really true? I'm an experienced database programmer learning
the Java/OO way of doing things and I'm puzzled that people use
Hibernate and similar tools to define objects, with the database
serving as just a passive serialization mechanism with no thought to
database theory. How can this possibly work in real life? Also I've
been told that stored procedures are not supported by Hibernate, is
that true? How can it be that 20 years of relational theory seems to be
getting thrown out overnight? Or am I just misinformed?

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

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.