Re: Oracle object-oriented database objects - opinions

tk wrote:

<snip>

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

We are using objects pretty extensively on my current project. We are not, however, using an object relational data model. The objects are just being used for the representation of semantic data constructs (very much like the 'multiplexing' you refer to). Combined with the pipeline table function enhancement in 9i, they are extremely useful.

However, there are some significant shortcomings still:

• no super() calls
• no 'interface' constructs
• no private or protected attributes or methods (everything's public)

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

I'd agree with this only if you tell me you won't allow anybody or anything to access the database directly. Absolutely everything must now go through the middle tier or you risk corrupting your data (from a business domain perspective).

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

At least half of the companies I've worked for have done the opposite. All business logic was written in PL/SQL and strictly enforced for absolutely every type of access to the data. There is no doubt in my mind that putting the business logic in the database was a far superior approach. Those companies were able to develop a wide variety of applications with a wide variety of tools all sharing the same business logic code base. They also had far fewer data corruption issues to do deal with (again corruption in the logical sense not the physical sense).

I'm certainly not suggesting you couldn't do that with a middle tier. However, every middle tier I've seen so far has been bypassed for this or that reason (application tool won't support it, need to get it out fast, somebody with Microsoft Access or whatever getting at the database, etc...).

Besides the fact that PL/SQL is far superior to absolutely everything out there when it comes to retrieving, validating and manipulating data in Oracle (the meat of most business logic). The attempts that I've seen at doing this work in Java were absolute nightmares of complexity compared to what would have been necessary with PL/SQL. They were also much slower because of vastly increased number of database roundtrips. Don't get me wrong, there are plenty of things that make much more since to do in other languages this just isn't one of them.

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

For anything non-trivial, this sounds like a bit of a fantasy (if not a nightmare).

<snip>

> 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 would disagree pretty strongly that this is the "whole point" but I'll leave that for another discussion. I think you are vastly underestimating the complexity of "swapping out" the database. In reality, most companies have significant hurdles to overcome if they are going to switch from Oracle to whatever. I would certainly concede that having a large base of PL/SQL code would add tons to that effort as well. However, as much as I've heard people talk about switching databases, I have yet to see anyone do it with a major system. If you really have a requirement to be completely database independent then that pretty much eliminates PL/SQL (as well as a slew of other features) from your toolbag. Other than companies developing shrink-wrap software though, I can't see this being a real requirement very often.

<snip>

> So what's the best way to use these Object-Oriented features of Oracle??
> (ie, the METHOD, TREAT, BASE-DERIVED)

Assuming you're not going to implement your business logic with PL/SQL, I'm not sure they are much use for you. I'd read up on pipeline table functions still, since they can be used to create programmatic data sources with object based structures. I find this extremely useful when you have a variety of interfaces/applications/reports that need to work with the same data (especially when it involves computations, aggregations, etc..).

Richard Kuhler Received on Fri Aug 15 2003 - 12:28:22 CDT