The short answer is, listen to your DBA. There are very few occasions where
an OODB is the proper way to go. Your DBA's advice is even more valid if
he/she happens to be familiar with OODB concepts.
Steve Lucord <steve.a.lucord_at_lmco.com> wrote in message
news:3859214A.F31B3F02_at_lmco.com...
> Alan Shein wrote:
>
> > Depends on your business needs. Could you provide some details?
> >
>
> I am more of an object-oriented programmer than a DBA. I read some
articles
> on mapping business objects to a relational database and saw an example in
a
> tutorial that split addresses and phone numbers into seperate tables. The
> actual dba is concerned performance problems making the extra read to
retrieve
> the address. I implemented lazy retrieval so the address is not actually
> retrieved unless the programmer requests address attributes. We are a web
> based application. I could imagine a performance hit if we processed
hundreds
> of thousands of transactions and needed an extra I/O for each. However,
for
> each user initiated transaction, we make less than 10 I/O calls.
>
> There are no business needs that would indicated one modeling technique
over
> the other. I chose to seperate the tables because that I was how I would
do
> it in an object-oriented application. Since I have no DBA knowledge to
defend
> the decision I am asking the internet community for advice. If its better
to
> combine the address data on the related table, then I would like to know
for
> the sake of future projects. It is also not too late to change the current
> model.
>
> Thanks.
>
>
Received on Thu Dec 16 1999 - 14:33:24 CST
