Re: Oracle object-oriented database objects - opinions

"tk" <theronk_at_charter.net> wrote i

> 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?

The Oracle terminology is a tad confusing. I would have prefered a CREATE OR REPLACE CLASS above a CREATE OR REPLACE TYPE .. AS OBJECT.

In OO terms, an Oracle object is not really an object until you instantiate it. This instantiation is either done via PL/SQL (i.e. creating a variable of that class), or when it is used as a column's data type in a table, or a table itself.

Thus IMO it is not much HOW you refer to them, but WHERE you refer to them. You can not run a transaction SQL against PL/SQL variable, even when it is a collection class object.

> 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?

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.

I strongly doubt that Oracle's OO features are commonly being used.. through no fault of these features itself.. simply because the average developer/DBA/analyst does *NOT* have any idea about real OO design and programming.

> 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).

IMO (and not so humble at all), THAT IS UTTER BS. I have heard them saying the same think TK.. and 3 tier smells. And that is a first hand smell btw. It stinks.

Cut it to the bone. Simplicity is what makes things work without the wheels coming off around every 2nd corner. Simplicity is putting business logic together with referential integrity to process and protect you data. INSIDE Oracle.

> 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.

That is IMO a serious design concept flaw. A database like Oracle is NOT just a storage system.

You want persisted classes? Try Delphi. Seriously. How about storing 100's of thousands of persistant classes on disk? How about the ability to load and search them within _seconds_? Been there. Done that. You do not need Oracle if that is the approach you want to take.

Networking persitant objects? Try DCOM. And it works a darn sight _better_ than Corba. (it is a fatal flaw to think that Microsoft cannot innovate)

Treating Oracle like it is merely a filing system deomonstrates IMO a serious lack of understanding about RDBMS (and Oracle specifically). The word idiot comes to mind.

> 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.

As I said - if that is the approach then you do not need Oracle. You can easily roll your own persistant class storage and retrieval system that is lot cheaper than Oracle.

And if you say "no" - then by that you recognise that not everything can be done in the middle tier. Which then begs the question.. just wtf are you doing trying to do everything in the middel tier?

(btw TK, with "you" I do not mean you personally - just ranting in the general direction of these Java 3-tier prophets that are more fundementalistic in their opinions and views than a suicide bomber).

> 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.

Ignorance is the real danger.

> 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).

That is ONLY a consideration IF you are a software vendor selling a product to customers running DIFFERENT db versions.

Are you in that business TK?

If not, then that point has no merrit. None at all.

> 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".

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

> So what's the best way to use these Object-Oriented features of Oracle??

A methodology that I have been using since the 80's. It is called CSL.

Common Sense... and Logic.

--
Billy