Re: acceptable way to program

From: steve <me_at_me.com>
Date: Sat, 1 Jan 2005 06:26:04 +0800
Message-ID: <0001HW.BDFBF2FC00008D66F04885B0_at_news.newsguy.com>


On Fri, 31 Dec 2004 16:32:39 +0800, DA Morgan wrote (in article <41d50d89$1_2_at_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. Received on Fri Dec 31 2004 - 23:26:04 CET

Original text of this message