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]

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.

 

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

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.

 

[thufir]

<http://directory.google.com/Top/Com..._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.

 

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

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

 

[steve]

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

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]

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!

 

[thufir]

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

steve, i took the liberty of cross-posting your original post to
comp.databases.oracle.misc, hope you don't mind!

 

[fishfry]

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]

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]

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]

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.

 

[Chris Uppal]

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]

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.

 

[Chris Smith]

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]

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

 

[Sudsy]

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

The goal is to implement the business logic in the middle layers,
removing it from the database tier. You end up using the database
as the incredibly fast and powerful resource it started out to be.
It's important from a portability prespective; would you really
want to rewrite all your stored procedures if/when you have to
migrate to another RDBMS?