> An update could end up
> having to write to multiple tables. So, I guess, you have to walk the 
tight
> rope between these issues, and having a perfectly normalized database.

You might want to rethink that statement.  The goal of a 
relational database is to have no redundant data.

If you have to update multiple tables in a transaction, so what?

That is certainly preferable to being required to ferret out all
the tables that store the same information, and must therefore be
updated together, as in a denormalized database.

Jared







[EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
 01/23/2003 09:15 AM
 Please respond to ORACLE-L

 
        To:     Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]>
        cc: 
        Subject:        Re: over-normalized?



How many join table operations do you perform, in most of the queries? As
more tables are added to the join, you take a performance hit? Plus, all
the space for the indexes on the additional tables? An update could end up
having to write to multiple tables. So, I guess, you have to walk the 
tight
rope between these issues, and having a perfectly normalized database.

To quote George Koch "No major application will run in third normal form".

Raj




  
                    "Saira Somani"   
                    <saira_somani@        To:     Multiple recipients of 
list ORACLE-L <[EMAIL PROTECTED]> 
                    yahoo.com>            cc:   
                    Sent by:              Subject:     over-normalized?    
 
                    [EMAIL PROTECTED]   
                    om  
  
  
                    January 23,  
                    2003 11:00 AM   
                    Please respond   
                    to ORACLE-L  
  
  




Is there such thing as an over-normalized database design?
What defines over-normalization? And what are its consequences? (Other
than the obvious degraded database performance and lots of tuning)

I hear rumblings that our ERP system is over-normalized.

Just curious,

Thanks!

Saira Somani
IT Support/Analyst
Hospital Logistics Inc.


-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: 
  INET: [EMAIL PROTECTED]

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: [EMAIL PROTECTED] (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: [EMAIL PROTECTED]

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: [EMAIL PROTECTED] (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).

Reply via email to