Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> RE: Databases & OO applications

RE: Databases & OO applications

From: Orr, Steve <>
Date: Fri, 25 Apr 2003 09:06:41 -0800
Message-ID: <>

I'm with you Jared. When it comes to "OBJECT" Oriented Programmers the key question is whether "OBJECT" is a noun or a verb. ;-)

The clash of relational and object oriented paradigms is interesting but the ultimate test is in the practical application-- where the rubber meets the road. If either your OO purity or 3NF purity hamper practical application then something is not right. Dogmatic, religious-like adherence to theory over practice leads one to strange, cultic behavior which I've observed on more than occasion. I guess we're not just talking computers here but geeks all too often succumb to dogmatism. ;-)

Speaking of which, what about embedding? (I'm not talking about the press in Iraq.) I appreciate that Oracle can store BLOBs but does anyone use nested tables? What about storing Java objects in the database. According to the OO cult, object oriented databases were supposed to have supplanted relational database years ago. What happened? ;-)

I guess I'm not a very good "believer" because I often break the rules when it suits me. I've sinned by violating Boyce-Codd normal form and I've been impure by creating objects and classes where the database wasn't just a storage medium. My conviction and intellect must be weak because I am unable to choose sides in this religious war.

Confessions of a fence setter,
Steve Orr
Bozeman, Montana

P.S. I recently did multiple inheritance in some Python code and it was really cool. There's something to this OO stuff but I sometimes have problems fully "instantiating" it in my brain.

-----Original Message-----
Sent: Thursday, April 24, 2003 11:52 AM
To: Multiple recipients of list ORACLE-L Importance: High

Interesting article, though I don't have time to read it all.

Another interesting quote:

One of the first questions people consider with this kind of thing is performance. Personally I don't think performance should be the first question. My philosophy is that most of the time you should focus on writing maintainable code. Then use a profiler to identify hot spots and then replace only those hot spots with faster but less clear code. The main reason I do this is because in most systems only a very small proportion of the code is actually performance critical, and it's much easier to improve the performance of well factored maintainable code.

I can't help but disagree with this. At a former employers site, the very first task I was given was
to improve the performance of a system that was very important, had high visibility at the executive
level, and was notoriosly slow.

Slow as in taking several hours to process 10,000 fairly simple claims.

The app itself had been written by some very good developers, at least in terms of application design and coding. What they knew about databases wouldn't fill a thimble.

Their code was so good, they won some kind of pretigious award from an OOP magazine, or some such thing.

But when it came to databases...

The first thing we did to speed it up was put the application on the database server, something
that was normally forbidden. This yielded a 40% reduction in runtime. This was due to the single
biggest wait being sqlnet waits. Did I mention this was a batch application?

The avg tcp packet size was 200 bytes. There were many millions per hour, I forget the exact number.

No wonder that getting it off the network made it faster, eh?

This was still a slow app though. The reasons for it's slowness are mentioned in the referenced article.

The app treated every piece of data as atomic, and looked it up one row at a time.

There was no way to speed this up, other than obvious things such as replacing
"delete * from tmptable" with "truncate table tmptable".

The final blow from this db unaware problem was at y2k. It didn't have a y2k problem.

It had a decade problem. Yes, the year was (still is) stored as a single digit.

Mr Fowler is giving short shrift to performance. He doesn't believe you should design
with performance in mind. I and many others have had to live with the results of
this philosophy.


"Pardee, Roy E" <>
Sent by:
 04/24/2003 09:11 AM
 Please respond to ORACLE-L  

        To:     Multiple recipients of list ORACLE-L <>
        Subject:        Databases & OO applications (was RE: J2EE Question)

Of possible interest--an influential OO guy writes about using SQL in OO applications:

Many application developers, particularly strong OO developers like myself,
tend to treat relational databases as a storage mechanism that is best hidden away. Frameworks exist who tout the advantages of shielding application developers from the complexities of SQL.

Yet SQL is much more than a simple data update and retrieval mechanism. SQL's query processing can perform many tasks. By hiding SQL, application developers are excluding a powerful tool.

In this article I want to explore the pros and cons of using rich SQL queries that may contain domain logic. I have to declare that I bring a OO bias to the discussion, but I've lived on the other side too. (One former client's OO expert group ran me out of the company because I was a "data modeler".)



Roy Pardee
SWFPAC Lockheed Martin IT
Extension 8487

-----Original Message-----
Sent: Thursday, April 24, 2003 7:47 AM
To: Multiple recipients of list ORACLE-L

I hit this constantly...

the developers say "oh, but the open source object program we are using can't handle concatenated keys, we need you to put another key in there"

they aren't lying to you, but how something in this day and age, with databases and relational theory matured, can NOT handle concatenated keys drives me nuts

Fat City Network Services    -- 858-538-5051
San Diego, California        -- Mailing list and web hosting services
To REMOVE yourself from this mailing list, send an E-Mail message to: (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). Received on Fri Apr 25 2003 - 12:06:41 CDT

Original text of this message