Re: Object .vs. Relational

Peter,

Thanks for the feedback. This is exactly the type of real-world experience I was hoping to tap into.

Thanks again.

Matt.

In article <3A08115F.650E2D33_at_mitre.org>,   Peter Sylvester <peters_at_mitre.org> wrote:
> From my limited use of Oracle's OO functionality, it does not appear
 to
> have the level of support that relational has.
>
> Examples:
>
> You don't have as much flexibility when altering OO structures after
> they are created. Once you have dependencies, you often have to drop
> everything and start over. A method that I have foud useful is to use
> standard relational structures, and then build OO views on top of them
> (although you may have to write some update trigger code).
>
> OO doesn't seem to be fully supported in all tools, such as
 relication.
>
> JDBC (and probably OCI/Pro*C) access to OO structures is more
> complicated and non-standard.
>
> OO *does* appear to be required to use Oracle's XML tools for working
> with nested and complex structures. (OO views work OK here).
>
> -Peter
>
> Matthew Fuller wrote:
> >
> > I did some searching on the board for this subject and only found
 old
> > messages with few responses. I'm hoping there's some more
 enlightened
> > folks out there now.
> >
> > Does anyone have any input on Object .vs. Relational database
 structure
> > in Oracle? Code being developed in our shop is OO (Java). Current
> > database architecture is "Object Relational" as we are using that
> > methodology along with the Spatial Data Option. Am considering
> > migrating to a fully object model.
> >
> > After digging through documentation I have the following perceptions
> > (please correct or confirm):
> > - Performance will not be "too" much different. It would seem that
> > Oracle is storing Object tables similar to relational tables (both
> > have "rowids", both can be indexed, etc.). I have to believe that
 the
> > way Oracle really physically stores and accesses the data is not
 that
> > much different after you get past the different coding techniques.
> > - Design/Development may be faster, and should at least be more
> > cohesive since both code and DB are in the same methodology.
> > - Learning curve for DBAs and Admins that are strictly "relational"
> > will have to be overcome, but this should be reasonably easy for my
> > group.
> >
> > Am I missing anything?
> >
> > TIA.
> >
> > Matt.
> >
> > Sent via Deja.com http://www.deja.com/
> > Before you buy.
>

Sent via Deja.com http://www.deja.com/
Before you buy. Received on Tue Nov 07 2000 - 10:05:03 CST