RE: Large databases

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. ( http://www.oreilly.com/catalog/oracle2/ )

At that, it was a minor infraction of normalization.

Maybe this would make a good project?

Jared

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

        To:     Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>
        cc: 
        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
"Effective

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: http://www.orafaq.net
-- 
Author: Stephen Lee
  INET: Stephen.Lee_at_DTAG.Com

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (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).




-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: 
  INET: Jared.Still_at_radisys.com

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (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).