Re: Oracle object-oriented database objects - opinions

> By the same token, is OO actuall *really* being used? I have seen many
> so-called OO implementations. Look at the code and design, and it is
> simply procedural code wrap into a few classes, without any thought of
> OO design.

First of all, thanks for your reply!!!

I must be lucky then as OO is actually being excercised rigerously at every position I have had the good fortune of being on (ie, extensive following of Gof design patterns as well as the Core J2EE patterns). I have had a chance to work with some very bright people (not including myself) and have been able to pick up on quite a few things.

> Treating Oracle like it is merely a filing system deomonstrates IMO a
> serious lack of understanding about RDBMS (and Oracle specifically).

Oh no. We're not treating Oracle like a filing system (I apologize if I gave you that impression). The tables and their relationship tables are normalized/indexed and constrained for the utmost performance. The relationships within the data models are quite normalized.

I fear there's a misunderstanding on what I said (perhaps on my part). The "data" model of the tables within the RDMS don't necessarily need to model the "business" object model. I'm not going to mention specific jobs but Oracle gurus that design the table relationships and such often abstract/normalize those relationships from the "business" domain. When a Business Object comes in and asks (for example) for billing statements and account information, the data may be gathered from various tables (to serve the purpose of normalization, etc...) that it never knows about. Maybe we're saying the same thing. We may have a middle tier method that calls a PL/SQL package to "get account information". That PL/SQL package may turn around and perform a bunch of joins from various entity tables (and relationship tables) to gather up all of the data in one nice ref cursor that the middle tier can "happily" read from. Same with updates/inserts. The middle tier can simply pass in array objects of data (or what have you) and the PL/SQL package(s) can multiplex them out across the various DB tables that make up the DB structure.

Other than serving a very important role as an adapter between the business and database structures, there's NOT much business (ie, decision making) logic going on in the PL/SQL code (at least in the environments that I have been in). Much of the decision-making logic in the PL/SQL code that I have seen involves the use of DECODE statements and date conversions as well as passing data over to a 3rd party interface (via the external routines, etc) which are basically internal to the packages themselves and the invokers know little to nothing about what's actually going on inside. The core of the PL/SQL routines that I have seen involves the gathering and multiplexing of data to be placed into/read from ref cursors and data structures.

> The word idiot comes to mind.

I was just asking for opinions on the usefullness of Oracles Object-Oriented features and when to use them.

> Are you in that business TK?

No...

> Everyone is a "guru" these days. Few though have the hands-on
> experience to make their opinion something to take seriously.

Well. The ones I was speaking of have 6-12 years of hands on Oracle and are Oracle 8 certified :-) One such gentleman has over 12 years hands on with it. I personally value their opinions very much so and am blown away with the Oracle knowledge that the 12+ year gentleman has (ie, guru DBA and PL/SQL programmer).

Don't get me wrong, so far I am liking PL/SQL and I can see a ton of cases to use it.

thanks!!! Received on Thu Aug 14 2003 - 09:20:42 CDT