acceptable way to program

[steve]

Hi,

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

I was always instructed on the purity of the data model, "normalize the
data" etc.

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

finally when they want to retrieve it they de-serialize the object., work on
it then re-serialize and stuff it back into the oracle blob.

to me this causes the following problems:

1. the object can become very big, and can only be recovered in it's
entirety, and if it contains pictures ,etc, it can become huge.
2. the object becomes "closed", in that it cannot be modified or checked in
situ
3. it cannot be searched , without de-serialization.
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

[DA Morgan]

steve wrote:

Hi,

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

I was always instructed on the purity of the data model, "normalize the
data" etc.

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

finally when they want to retrieve it they de-serialize the object., work on
it then re-serialize and stuff it back into the oracle blob.

to me this causes the following problems:

1. the object can become very big, and can only be recovered in it's
entirety, and if it contains pictures ,etc, it can become huge.
2. the object becomes "closed", in that it cannot be modified or checked in
situ
3. it cannot be searched , without de-serialization.
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

Store relationally and create an API from package procedures to handle
the transactions between the database and the front-end application.

A good rule of thumb is that if you can't use Crystal Reports to query
the database structure with ease ... you have created a nightmare. What
you describe, above, is a nightmare.
--
Daniel A. Morgan
University of Washington
da******@x.washington.edu
(replace 'x' with 'u' to respond)

[thufir]

steve wrote:
[..]

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.
so you've decided on a relational database? yes, Cobb's (?) rules,
first normal form, second... etc apply in that case. as DA Morgan
(surely not the mathematician, de morgan?) said, the practice you
described is the worst of both worlds: a total mis-use of a relational
database which, as you state, should be normalized as much as is
practical/possible.

if a (relational) database isn't normalized, to whatever extent, it's
open to corruption. In the situation you described maintenace is
probably a PITA..?
using an "object approach" would make it very simple, but the
size of the resulting object could be very large.

instead of a relational database there're a multitude of options:

POJO (plain old java object)
xml
JDO
....i dunno the rest, but there's gotta be tons!

if you've already decided on a relational database (oracle) then your
question as to how to implement that effectively answers itself in many
regards.

you're real question, i infer: "what are the alternatives to a
relational database?" and trying to find the best one for your needs.
however, you seem to have already decided on oracle, so it's more
hypothetical than practical.

--Thufir

[ByteCoder]

steve wrote:

Hi,

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

I was always instructed on the purity of the data model, "normalize the
data" etc.

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

finally when they want to retrieve it they de-serialize the object., work on
it then re-serialize and stuff it back into the oracle blob.

to me this causes the following problems:

1. the object can become very big, and can only be recovered in it's
entirety, and if it contains pictures ,etc, it can become huge.
2. the object becomes "closed", in that it cannot be modified or checked in
situ
3. it cannot be searched , without de-serialization.
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.

As you said above. If you have a proper data model, it should be a piece
of cake. :)

--
-------------
- ByteCoder - ...I see stupid people
-------------
Curiosity *Skilled* the cat

[thufir]

<http://directory.google.com/Top/Computers/Programming/Languages/Java/Databases_and_Persistence/Database_Management_Systems_-_DBMS/Object-Relational/>

<http://objectstyle.org/cayenne/>

<http://www-306.ibm.com/software/data/cloudscape/>

<http://www.hibernate.org/>

in no particular order :)

note that the term "object-relational mapping" is what you're after,
probably.

--Thufir

[Tom Dyess]

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.

The next question would be where to store the images. BLOB or files. Both
approaches have their downfalls.

BLOBS are good because you have a centralized location for all your data
(Oracle DB) but that problem is your exports will quickly get huge and will
become a DBA nightmare (having to export a table at a time).

Keeping your files on the filesystem requires two storage mechanisms, the DB
and the filesystem. It's additional overhead to backup the files every
night, but overall, this is the approach with the least hastle overall.

"thufir" <th**********@mail.com> wrote in message
news:11**********************@z14g2000cwz.googlegr oups.com...

<http://directory.google.com/Top/Computers/Programming/Languages/Java/Databases_and_Persistence/Database_Management_Systems_-_DBMS/Object-Relational/>

<http://objectstyle.org/cayenne/>

<http://www-306.ibm.com/software/data/cloudscape/>

<http://www.hibernate.org/>

in no particular order :)

note that the term "object-relational mapping" is what you're after,
probably.

--Thufir

[steve]

On Fri, 31 Dec 2004 16:32:39 +0800, DA Morgan wrote
(in article <41**********@127.0.0.1>):

steve wrote:

Hi,

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

I was always instructed on the purity of the data model, "normalize the
data" etc.

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

finally when they want to retrieve it they de-serialize the object., work
on
it then re-serialize and stuff it back into the oracle blob.

to me this causes the following problems:

1. the object can become very big, and can only be recovered in it's
entirety, and if it contains pictures ,etc, it can become huge.
2. the object becomes "closed", in that it cannot be modified or checked
in
situ
3. it cannot be searched , without de-serialization.
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

Store relationally and create an API from package procedures to handle
the transactions between the database and the front-end application.

A good rule of thumb is that if you can't use Crystal Reports to query
the database structure with ease ... you have created a nightmare. What
you describe, above, is a nightmare.

thanks guys!!

I thought perhaps , I was out of date.

Anyway as we have a brand spanking new 10g , oracle and a rational layout
it is.

[Ann]

"steve" <[e-mail]> wrote in message
news:00*****************************@news.newsguy. com...

Hi,

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

I was always instructed on the purity of the data model, "normalize the
data" etc.

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

finally when they want to retrieve it they de-serialize the object., work on it then re-serialize and stuff it back into the oracle blob.

to me this causes the following problems:

1. the object can become very big, and can only be recovered in it's
entirety, and if it contains pictures ,etc, it can become huge.
2. the object becomes "closed", in that it cannot be modified or checked in situ
3. it cannot be searched , without de-serialization.
How do you sort on a field that contains just picures (not pictures in
objects.)


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

[steve]

On Sat, 1 Jan 2005 12:23:38 +0800, Ann wrote
(in article <eBpBd.311721$HA.34608@attbi_s01>):

"steve" <[e-mail]> wrote in message
news:00*****************************@news.newsguy. com...

Hi,

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

I was always instructed on the purity of the data model, "normalize the
data" etc.

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

blob

column.

finally when they want to retrieve it they de-serialize the object., work

on

it then re-serialize and stuff it back into the oracle blob.

to me this causes the following problems:

1. the object can become very big, and can only be recovered in it's
entirety, and if it contains pictures ,etc, it can become huge.
2. the object becomes "closed", in that it cannot be modified or checked

in

situ
3. it cannot be searched , without de-serialization.

How do you sort on a field that contains just picures (not pictures in
objects.)

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

by giving the picture a key index, that ties back to a master object.

If for example i have a factory record, and 50 ( Health & safety) pictures
attached to that factory record, via a key,
If i follow some peoples current advice ( Serialize, Serialize!!! ), i would
have to de-serialize an object of about 6MB, either to disk or into memory.

currently , i bring the master factory record over, then bring the pictures
over on the fly. ( actually i bring 3k thumb nails over first), then pictures
if requested by the user.
my main point , was that Whilst i have no formal background in data
management, or oracle databases, or system management ,etc .
I am the "main man" by default, because i am technical ! ( you gotta love
some companies)

Therefore because i don't know I ask.

steve

[Ann]

"steve" <[e-mail]> wrote in message
news:00*****************************@news.newsguy. com...

On Sat, 1 Jan 2005 12:23:38 +0800, Ann wrote
(in article <eBpBd.311721$HA.34608@attbi_s01>):

"steve" <[e-mail]> wrote in message
news:00*****************************@news.newsguy. com...

Hi,

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

I was always instructed on the purity of the data model, "normalize the data" etc.

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

blob

column.

finally when they want to retrieve it they de-serialize the object.,

work on

it then re-serialize and stuff it back into the oracle blob.

to me this causes the following problems:

1. the object can become very big, and can only be recovered in it's
entirety, and if it contains pictures ,etc, it can become huge.
2. the object becomes "closed", in that it cannot be modified or

checked in

situ
3. it cannot be searched , without de-serialization.
How do you sort on a field that contains just picures (not pictures in
objects.)

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

by giving the picture a key index, that ties back to a master object.

So then you can sort on the blobs by giving them a key index!

If for example i have a factory record, and 50 ( Health & safety) pictures
attached to that factory record, via a key,
If i follow some peoples current advice ( Serialize, Serialize!!! ), i would have to de-serialize an object of about 6MB, either to disk or into memory.
currently , i bring the master factory record over, then bring the pictures over on the fly. ( actually i bring 3k thumb nails over first), then pictures if requested by the user.
my main point , was that Whilst i have no formal background in data
management, or oracle databases, or system management ,etc .
I am the "main man" by default, because i am technical ! ( you gotta love some companies)

Therefore because i don't know I ask.

steve

[fishfry]

In article <11**********************@c13g2000cwb.googlegroups .com>,
"thufir" <th**********@mail.com> wrote:

steve wrote:
[..]

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.

so you've decided on a relational database? yes, Cobb's (?) rules,

Codd, Dr. E.F. Codd. http://www.itworld.com/nl/db_mgr/05072001/

[fishfry]

In article <Ih****************@bignews6.bellsouth.net>,
"Tom Dyess" <td****@dysr.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?

[Robert kebernet Cooper]

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.

[ByteCoder]

fishfry wrote:

In article <Ih****************@bignews6.bellsouth.net>,
"Tom Dyess" <td****@dysr.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?

Well, I'd do it your way. Creating objects based on information returned
from a database query is much better than just storing the object in the
database, because if you do it 'right' other programs can also use the data.

--
-------------
- ByteCoder - ...I see stupid people
-------------
Curiosity *Skilled* the cat

[Chris Uppal]

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

It may help to consider the difference between:

a) a program (or group of closely related programs) that
happens to require (ACID) persistence.

b) a program that is required to manipulate independently-existing
data in a more-or-less public repository (database).

The difference is in whether the program or the data is primary.

The two are not the same, although the same technology /can/ be used to
approach both kinds of requirement.

In my opinion, O-R technologies are mostly about (a) -- that is to say they
provide a poor man's object database. As such the issues you raise are largely
irrelevant. (Of course, that's not to say that a /real/ object database should
only be viewed as a mere persistency mechanism, but the only one of those I
know of is GemStone.)

Many real life uses of databases, though, don't fall into the (a) category.
The data itself is /at least/ as important as the program(s) that manipulate
it. Relational databases (and relational DB theory) are mostly about that
scenario.

I, personally, think there's a fairly severe conceptual mismatch between
table-centric relational databases and object-centric programming. That
manifests in a number of ways, one of them is that it's awkward to do clean OO
programming against externally defined data (scenario b). As a result,
programmers looking for a "quick fix" will naturally tend to try to use OR
technology to paper over the gap. Whether that works well must depend on a
number of factors, and I can see why Tom might characterise it as "mostly hype"
(I don't have enough experience of OR to agree or disagree), but I think that
what's really happening is that a tool designed for one purpose ("poor man's
object database") is being used for another purpose. When you get right down
to it, that is little more than a hack. Like all hacks, it /might/ work well,
even very well, for some purpose, but it's not the same thing as using the
right tool for the job.

-- chris

[DA Morgan]

fishfry wrote:

In article <Ih****************@bignews6.bellsouth.net>,
"Tom Dyess" <td****@dysr.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.
--
Daniel A. Morgan
University of Washington
da******@x.washington.edu
(replace 'x' with 'u' to respond)

[Chris Smith]

Chris Uppal <ch*********@metagnostic.REMOVE-THIS.org> wrote:

It may help to consider the difference between:

a) a program (or group of closely related programs) that
happens to require (ACID) persistence.

b) a program that is required to manipulate independently-existing
data in a more-or-less public repository (database).
Indeed, I do find that to be a useful distinction. But,
In my opinion, O-R technologies are mostly about (a) -- that is to say they
provide a poor man's object database.

This isn't exactly true. There are a number of factors to consider when
making use of O/R mapping technologies, and this is one of them. Some
such technologies are extremely limited in terms of how their data is
stored, and are only suitable for application-private data that uses a
relational database by coincidence. Others are considerably more
flexible, and can deal with data that's represented in a number of ways,
and map from there to a number of different OO models.

Hibernate is a good example of the latter. I enjoy using Hibernate
because I can do (or get someone else to do) intelligent database design
without thinking of my application, and then I can pretty easily create
an OO model of that data using Hibernate that's fairly easy to use from
Java. Same goes for a pre-existing database. Indeed, I can create
different OO models for different applications (which ought to be the
way O/R mappers are used; good O/R mapping is a functional concern, and
is not inherent in the data itself) and they will work together
flawlessly, making connections to the same database.

That said, I know of no O/R mapper that's really universally outstanding
in being able to map an existing database schema in an ideal way.
Generally, you'll end up with some quite quirks in the OO model of the
data. I imagine more flexibility could be provided by products in the
future. Nevertheless, I don't think it's fair to characterize use of an
O/R mapper for this as a hack, or to claim that it's different from the
intended usage of the tool.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

[Chris Smith]

fishfry <BL**************@your-mailbox.com> wrote:

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?

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:

- Use of Hibernate when it's a poor idea. If a task is inherently
suited to a tabular view of data, then Hibernate isn't necessarily the
best tool. Also, if an application looks at data in a lot of different
combinations and does a lot of selecting of specific columns and joining
of tables (particularly in ways that aren't easily predicted at
development time), then Hibernate is obviously not the best way to do
this. These are tasks which are best accomplished in a relational
model. Use of Hibernate to write an application that naturally fits
into the relational model is a bad idea.

- Use of Hibernate's tool to convert existing objects to an auto-
generated database schema, if that schema might be used by a separate
application. That derives the data model from the functional model of
that data in a specific application, and that is a bad idea for data
that will be shared between multiple applications.

It should be mentioned here that I am referring to data that might be
used by multiple applications *right now* under current requirements.
If the data might be used three years from now by a separate application
and the current application isn't that awfully proliferant, I wouldn't
worry about it. It only takes a weekend or so to write a tool that
moves data from the old database to a new database schema if there's no
live application.

As for stored procedures, it is true that current production releases of
Hibernate cannot use stored procedures for the simple CRUD tasks that
are implemented by Hibernate. You can, however, call stored procedures
in the database just fine. Version 3 can even use stored procedures for
CRUD operations, and there's a beta available for version 3.
Nevertheless, it would be a royal pain to write stored procedures for
every little thing like that. Data validity can be better checked in
the database with constraints and triggers without interfering with the
application interface. Stored procedures (at least, though exposed to
applications) are best reserved for domain-specific logic, and don't
need Hibernate to be called anyway.

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.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

[Chas Douglass]

DA Morgan <da******@x.washington.edu> wrote in
news:41**********@127.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

[steve]

On Sun, 2 Jan 2005 18:00:15 +0800, Robert kebernet Cooper wrote
(in article <11*********************@z14g2000cwz.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

[Robert kebernet Cooper]

steve wrote:

On Sun, 2 Jan 2005 18:00:15 +0800, Robert kebernet Cooper wrote
(in article <11*********************@z14g2000cwz.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.

[DA Morgan]

Chas Douglass wrote:

DA Morgan <da******@x.washington.edu> wrote in
news:41**********@127.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
da******@x.washington.edu
(replace 'x' with 'u' to respond)

[Chas Douglass]

DA Morgan <da******@x.washington.edu> wrote in
news:41**********@127.0.0.1:

Chas Douglass wrote:

DA Morgan <da******@x.washington.edu> wrote in
news:41**********@127.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.

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]

Chas Douglass wrote:

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.

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.

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.
(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
da******@x.washington.edu
(replace 'x' with 'u' to respond)

[Chas Douglass]

DA Morgan <da******@x.washington.edu> wrote in
news:41**********@127.0.0.1:

Chas Douglass wrote:

[snip stuff I agree with]

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.

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

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?

(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

[DA Morgan]

Chas Douglass wrote:

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.

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

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

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

[Haximus]

"steve" <[e-mail]> wrote in message
news:00*****************************@news.newsguy. com...

<snip>

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]

"DA Morgan" <da******@x.washington.edu> wrote in message
news:41**********@127.0.0.1...

fishfry wrote:

In article <Ih****************@bignews6.bellsouth.net>,
"Tom Dyess" <td****@dysr.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."

[Mark C. Stock]

"Haximus" <[e-mail]> wrote in message news:KEVRd.13245$NN.11844@edtnps89...

"DA Morgan" <da******@x.washington.edu> wrote in message
news:41**********@127.0.0.1...

fishfry wrote:

In article <Ih****************@bignews6.bellsouth.net>,
"Tom Dyess" <td****@dysr.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

[Haximus]

"Mark C. Stock" <mcstockX@Xenquery .com> wrote in message
news:_4********************@comcast.com...

"Haximus" <[e-mail]> wrote in message news:KEVRd.13245$NN.11844@edtnps89...

"DA Morgan" <da******@x.washington.edu> wrote in message
news:41**********@127.0.0.1...

fishfry wrote:
In article <Ih****************@bignews6.bellsouth.net>,
"Tom Dyess" <td****@dysr.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.