Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> RE: Large databases

RE: Large databases

From: Orr, Steve <>
Date: Fri, 18 Apr 2003 11:02:17 -0800
Message-ID: <>

Just to add a few thoughts fwiw...

Sometimes a denormalized design performs worse. Normalized tables are better for OLTP with granular updates. If you have to update repeating values in denormalized tables then that's a performance hit and a design flaw.

Denormalized tables for reporting can perform better because you don't have to go to a lookup table to get a description. (For some odd reason users don't like unintelligent key number code values but prefer to see descriptions in reports. ;-)

But you can have a hybrid approach where normalized table values are copied to denormalized reporting tables via triggers or materialized views. This can also be done to maintain summary data. With a few well placed triggers you can have your cake and eat it too.

I guess the main point is that a reasoned, balanced approach is in order. If one dogmatically clings to guiding principles and makes them into hardfast rules then one is letting rules make the decisions instead of sound reasoning. The MATH is in the theory (relational), the ART is in the application.


-----Original Message-----
Sent: Friday, April 18, 2003 12:12 PM
To: Multiple recipients of list ORACLE-L Importance: High

I would suspect some fault application design if they were joining 13 tables. That is not normally necessary.

Nomalized databases, in my experience, are faster than most people think or expect, including me.

One such example from several years ago was an application we built from the ground up, including the schema design.

The app had to accept packets over an X25 link, adjudicate a pharmacy claim and send the results back to the pharmacy.

The allowable time for an end to end transaction was 9 seconds.

IIRC, it usually ran in less than 2 seconds.

That database was for the most part normalized, or as normalized as we were able to make it. It was our first project with an RDMBS.

There was one table we couldn't quite figure out how to normalize properly. The code that accessed that table was ridiculously complex, and would have been significantly simpler had we normalized.

There always seems to be a lot of anecdotal evidence proclaiming that normalization cannot be used to create a performant database, but there never seems to be any numbers to back it up.

The closest I've seen is Gurry and Corrigan's references to putting all code lookup tables into a single table to speed up a system. ( )

At that, it was a minor infraction of normalization.

Maybe this would make a good project?


Stephen Lee <Stephen.Lee_at_DTAG.Com>
Sent by:
 04/17/2003 07:46 PM
 Please respond to ORACLE-L  

        To:     Multiple recipients of list ORACLE-L <>
        Subject:        RE: Large databases

After dragging Kevin Loney's name into discussion, I thought I should give the reference. So I scrounged around and found the book. It's the Oracle DBA Handbook for Oracle 7.3; page 246 in Chapter 8 "Database Tuning".

The author first quotes another author to start the sub-topic of

Table Design". The quote is:
"No major application will run in Third Normal Form" -- George Koch from
Oracle 7, The Complete Reference.

Kevin (or whoever wrote this section) goes on to write:

No matter how well designed your database is, poor table design will lead to
poor performance. Not only that, but overly rigid adherence to relational table design will lead to poor performance. That is due to the fact that while fully relational table designs (said to be in the Third Normal Form) are logically desirable, they are physically undesirable.

The problem with such designs is that although they accurately reflect the ways in which an application's data is related to other data, they do not reflect the normal access paths that users will employ to access that data.

... the discussion goes on until we get to ...

User-centered table design, rather than theory-centered table design, will yield systems that better meet the users' requirements.

And now a few words from our sponsor:

As I thought about the application I mentioned in a previous post, I recalled that there were joins of 13 tables. As one might suspect, these were a little on the slow side. And all the king's horses and all the king's men couldn't speed them up. And don't think they didn't try.

"Uh, can you do some performance tuning on this query?"

"HUH?!?! You're joining 13 tables here!"

I recall somebody deriding a non-fully normalized database as being a maintenance problem. Well ... How would like to maintain the SQL for the baby (Rosemary's, of course) of which I speak?

Please see the official ORACLE-L FAQ:
Author: Orr, Steve

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 18 2003 - 14:02:17 CDT

Original text of this message