dbTalk Databases Forums  

acceptable way to program

comp.databases.oracle comp.databases.oracle


Discuss acceptable way to program in the comp.databases.oracle forum.



Reply
 
Thread Tools Display Modes
  #1  
Old   
steve
 
Posts: n/a

Default acceptable way to program - 12-31-2004 , 01:38 AM






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




Reply With Quote
  #2  
Old   
DA Morgan
 
Posts: n/a

Default Re: acceptable way to program - 12-31-2004 , 02:32 AM






steve wrote:
Quote:
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.washington.edu
(replace 'x' with 'u' to respond)


Reply With Quote
  #3  
Old   
thufir
 
Posts: n/a

Default Re: acceptable way to program - 12-31-2004 , 03:35 AM



steve wrote:
[..]
Quote:
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..?

Quote:
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



Reply With Quote
  #4  
Old   
ByteCoder
 
Posts: n/a

Default Re: acceptable way to program - 12-31-2004 , 03:45 AM



steve wrote:
Quote:
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


Reply With Quote
  #5  
Old   
thufir
 
Posts: n/a

Default Re: acceptable way to program - 12-31-2004 , 03:51 AM



<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


Reply With Quote
  #6  
Old   
Tom Dyess
 
Posts: n/a

Default Re: acceptable way to program - 12-31-2004 , 03:14 PM



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" <thufir.hawat (AT) mail (DOT) com> wrote

Quote:
http://directory.google.com/Top/Comp...ct-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




Reply With Quote
  #7  
Old   
steve
 
Posts: n/a

Default Re: acceptable way to program - 12-31-2004 , 04:26 PM



On Fri, 31 Dec 2004 16:32:39 +0800, DA Morgan wrote
(in article <41d50d89$1_2 (AT) 127 (DOT) 0.0.1>):

Quote:
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.



Reply With Quote
  #8  
Old   
Ann
 
Posts: n/a

Default Re: acceptable way to program - 12-31-2004 , 10:23 PM




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

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

Quote:

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






Reply With Quote
  #9  
Old   
steve
 
Posts: n/a

Default Re: acceptable way to program - 01-01-2005 , 04:36 AM



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

Quote:
"steve" <me (AT) me (DOT) com> wrote in message
news:0001HW.BDFB22EC00191A71F03055B0 (AT) news (DOT) 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












Reply With Quote
  #10  
Old   
Ann
 
Posts: n/a

Default Re: acceptable way to program - 01-01-2005 , 12:14 PM




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

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


"steve" <me (AT) me (DOT) com> wrote in message
news:0001HW.BDFB22EC00191A71F03055B0 (AT) news (DOT) 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!

Quote:
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













Reply With Quote
Reply




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off



Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.