Re: ORDBMS references ?

Riad,

Glad the info helped a bit.

As far as the performance of OO .vs. OR .vs. good ole relational, I don't have alot of concrete experience to draw on (other than I know that good ole relational is really excellent when designed and tuned correctly). This makes it difficult for me to validate or refute your arguments.

I work in a company where we are using the Object-relational model only because a large part of what we do is spatially oriented. In order to get the most out of Oracle Spatial (especially since release 8.1.6, you pretty much have to go with an Object-Relational model). This has worked well for our data, but keep in mind that we are not fully exploiting OR or OO.

Based on the one reply in my previous message I did some playing around with creating types and then referencing those types in other types. As the post had suggested, altering types and their corresponding tables once they are created is all but impossible. I agree with that posters comments that altering the database basically involves a drop and rebuild of the entire schema. This may be fine during development, but whatcha gonna do when you have data in that schema? Sure, you can customize scripts to back it up into a different schema, rebuild and "migrate" your data to the new schema; but that seems an awfully hefty price to pay just to use the OO methodology.

Having said all of this, I'm willing to bet all sorts of money that the OO and OR models will eventually prevail over good ole relational, but we're just not quite there yet. I look for Oracle to start remedying this problem with more support for OO and OR built in soon.

Matt.

In article <90dk23$kd$1_at_nnrp1.deja.com>,   iamthedude_at_my-deja.com wrote:
>
>
> Hello,
>
> Thanks for your answer. I took a look at your post.
> Well, typically, that's these kind of real experiences I am looking
 for.
> I am very surprised that no book has been dedicated to that.
>
> I am also surprised that you think performance won't be that superior.
> Think of it, rather than doing jointures all the time, REF is a pseudo
> direct link to the row we are looking for (or ARRAY of REF for a
> reference to multiple rows). I cannot imagine that this won't increase
> performance dramatically.
>
> Typically, for a complaex business model (say of a bank, a billing
> system, CRM, ERP, etc), there are a lot of "relations" that would
> benefit from that. Usually, the user application or the middle-tier
> application accesses the data using only the defined business
 relations
> (like customer to contracts, contract to parameters, etc). So the link
> could be precomputed and stored, logical ROWID could do the job, but
> REF is much better because it has an OO feature...
>
> Well, in fact, I am about to embark on a complex three-tier project.
 It
> would be very sad and a waste of time to start working with OO feature
> of Oracle to find out finally that it sucks or immature and not handy
> to manipulate (I found no tool so far to visually manipulate Objects
> data for Oracle 8i, TOAD does manipulate structures, but not the
> data)...
>
> Would appreciate your comments and from others as well...
>
> Best regards
> Riad
>
> In article <90199q$gbi$1_at_nnrp1.deja.com>,
> Matthew Fuller <matthewlf_at_my-deja.com> wrote:
> >
> > Riad,
> >
> > Is the documentation you are referring to "Oracle8i Application
> > Developer's Guide - Object-Relational Features Release 2 (8.1.6)"?
> >
> > If not, check it out... I think it will help. It's available on
 OTN.
> >
> > Also, check out this thread. It's a message I posted a couple of
 weeks
> > ago with some replies.
> >
> > http://www.deja.com/viewthread.xp?
> > AN=690468580&group=comp.databases.oracle.server
> >
> > HTH.
> >
> > Matt.
> >
> > Sent via Deja.com http://www.deja.com/
> > Before you buy.
> >
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>

Sent via Deja.com http://www.deja.com/
Before you buy. Received on Mon Dec 04 2000 - 10:19:39 CST