Re: Guidelines for using Oracle 9i Object Relational Features

"DA Morgan" <damorgan_at_exesolutions.com> wrote in message news:3E21F303.ED057FFC_at_exesolutions.com...
> ctcgag_at_hotmail.com wrote:
>
> > DA Morgan <damorgan_at_exesolutions.com> wrote:
> >
> > > I would stay as far away from OO in the database as you can.
> > ...
> > >
> > > And in the case of writing against a database you should not be
putting
> > > any SQL into the front-end unless the object of your development is to
> > > make something difficult to tune, difficult to upgrade, and a monster
to
> > > debug. Don't believe me? Ask people here how much they love Siebel and
> > > PeopleSoft.
> >
> > I'm not sure what you *are* advice would be here. If you shouldn't talk
> > to the database through objects, and you shouldn't talk to it through
> > SQL, what is left?
> >
> > Thanks,
> >
> > Xho
> >
> > --
> > -------------------- http://NewsReader.Com/ --------------------
> > Usenet Newsgroup Service New Rate! $9.95/Month 50GB
>
> Put objects into the front-end and middle tier. But don't use the OO
features
> in the database.
>
> Put all SQL into the database in the form of packages (not independent
> procedures and functions). Do not put SQL into the front-end. Just have
the
> front-end pass through the parameters but leave the SQL in the back-end.
> Tuning and debugging front-end SQL is somewhere between miserable and
> impossible depending on the environment.
>
> Daniel Morgan

Yes, I agree with this.

Client side OO is perfectly reasonable. Database side OO is a waste of time, as far as Oracle's current offerings are concerned.

IMHO, Oracle made a half-assed attempt to keep up with Informix a few years ago, and are now lumbered with the 'features'.

Forget 'Object-Relational' is my recommendation. Oracle is a RELATIONAL database, and a damned fine one at that. And I'm pragmatic enough to to ignore their marketing mistakes.

Regards,
Paul Received on Tue Jan 14 2003 - 14:18:09 CST