acceptable way to program

**DA Morgan** · Jun 27 '08, 06:54 PM

Re: acceptable way to program

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
damorgan@x.wash ington.edu
(replace 'x' with 'u' to respond)

**thufir** · Jun 27 '08, 06:54 PM

Re: acceptable way to program

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** · Jun 27 '08, 06:54 PM

Re: acceptable way to program

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

**steve** · Jun 27 '08, 06:54 PM

Re: acceptable way to program

On Fri, 31 Dec 2004 16:32:39 +0800, DA Morgan wrote
(in article <41d50d89$1_2@1 27.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** · Jun 27 '08, 06:54 PM

Re: acceptable way to program

"steve" <me@me.comwro te in message
news:0001HW.BDF B22EC00191A71F0 3055B0@news.new sguy.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** · Jun 27 '08, 06:55 PM

Re: acceptable way to program

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

>
"steve" <me@me.comwro te in message
news:0001HW.BDF B22EC00191A71F0 3055B0@news.new sguy.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** · Jun 27 '08, 06:55 PM

Re: acceptable way to program

"steve" <me@me.comwro te in message
news:0001HW.BDF C9E400028B19EF0 3055B0@news.new sguy.com...

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

"steve" <me@me.comwro te in message
news:0001HW.BDF B22EC00191A71F0 3055B0@news.new sguy.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** · Jun 27 '08, 06:55 PM

Re: acceptable way to program

In article <1104485720.164 105.110250@c13g 2000cwb.googleg roups.com>,
"thufir" <thufir.hawat@m ail.comwrote:

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** · Jun 27 '08, 06:55 PM

Re: acceptable way to program

In article <IhjBd.5746$6i. 1873@bignews6.b ellsouth.net>,
"Tom Dyess" <tdyess@dysr.co mwrote:

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** · Jun 27 '08, 06:55 PM

Re: acceptable way to program

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** · Jun 27 '08, 06:55 PM

Re: acceptable way to program

fishfry wrote:

In article <IhjBd.5746$6i. 1873@bignews6.b ellsouth.net>,
"Tom Dyess" <tdyess@dysr.co mwrote:
>
>

>>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** · Jun 27 '08, 06:55 PM

Re: acceptable way to program

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** · Jun 27 '08, 06:55 PM

Re: acceptable way to program

fishfry wrote:

In article <IhjBd.5746$6i. 1873@bignews6.b ellsouth.net>,
"Tom Dyess" <tdyess@dysr.co mwrote:
>
>

>>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
damorgan@x.wash ington.edu
(replace 'x' with 'u' to respond)

**Chris Smith** · Jun 27 '08, 06:55 PM

Re: acceptable way to program

Chris Uppal <chris.uppal@me tagnostic.REMOV E-THIS.orgwrote:

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.

--

https://www.designacourse.com

The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

acceptable way to program

acceptable way to program

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment