Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.misc -> Oracle object-oriented database objects - opinions

Oracle object-oriented database objects - opinions

From: tk <theronk_at_charter.net>
Date: Wed, 13 Aug 2003 22:02:01 -0600
Message-ID: <vjluj7beu7i195@corp.supernews.com>


Hope I'm not getting on folks nerves here :-) Just wanted to ask for more opinions as I'm picking up PL/SQL quite well. I've spent about 2-3 hours daily for the past few weeks and am just about finished reading (and working out alot of examples) my 2nd PL/SQL book.

I have an object-oriented programming background (ie, C++ and Java) for the past 12+ years so I'm quite comfortable with the methodology. I noticed Oracle's newer support for Application Objects (ie, Polymorphism/inheritance)...

A few questions:
1. What's the difference between an oracle object that supports inheritance and an oracle object that are triggers, procedures, packages, datatypes, etc?? Do you refer to the object-oriented objects by a different name than the regular database objects?

2. As neat as it is that Oracle supports this "newer" type of object which allows subtyping, how many out there are *really* using this feature? I mean, what I'm getting at is that this promotes "business" logic in the database which is (by many *but* I'm nuetral so I'm not going to say this is right or wrong) considered inappropriate (especially in a 3-tier architecture where the business logic should really be contained within the middle tier). Many positions that I have worked on typically have the business logic abstracted from the database and the database serves as a means of persisting the data model rather than the application structure. In all cases, the data models are abstracted from the domain structure such that the models and relationships between tables can still remain in-tact
(with little to no change) while the business model (in the client or middle
tier) can continually go thru semantical changes. It just seems to me that utilizing these object-oriented features within PL/SQL can be "slightly" dangerous as you're locking your business logic into the database. So the whole point of 3-tier architecture is to be able to swap in/out the client portion (switching the ui) and the db-portion (ie, switching database products).

I can see in a situation where one is using something like Oracle forms and the Database. In that case, maybe you don't have a true middle tier and then can offload business logic with PL/SQL.

A few other Oracle gurus I have spoken to feel this way too. They say "It's neat that Oracle supports this but it's not going to be utilized much as application logic should typically be abstracted from the data model".

So what's the best way to use these Object-Oriented features of Oracle??
(ie, the METHOD, TREAT, BASE-DERIVED) Sorry for the "windbag" questions!!!

thanks... Received on Wed Aug 13 2003 - 23:02:01 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US