RE: Normalization

  • From: Bob Lofstrand <blofstrand@xxxxxxxxxx>
  • To: "'oracle-l@xxxxxxxxxxxxx'" <oracle-l@xxxxxxxxxxxxx>
  • Date: Thu, 29 Jul 2004 11:06:23 -0500

I have to disagree. With materialized views I see no reason at all to
denormalize. Keep the base tables fully normalized and speed your queries by
pre-joining into materialize views. Correctness and speed. The only price is
disk space and that is a small price to pay to avoid inconsistant data.

-----Original Message-----
From: Juan Carlos Reyes Pacheco [mailto:jreyes@xxxxxxxxxxxxxxxx]
Sent: Thursday, July 29, 2004 10:48 AM
To: oracle-l@xxxxxxxxxxxxx
Subject: Re: Normalization


Hi Paul
I am not an expert, but yes trying to become "expert".

 Q: What are the basic guidelines one should keep in mind while
designing a database? Is denormalization always good?
 
In simple words.
The reason to normalize is don't duplicate data fooly
The reason to denormalize is don't get you boss kick your ass, because a
query is taking too much time.

There is a limit when tuning, when you can't get more performance, unless
you denormalize, buy hardware or move to RAC.


The guideline is performance, and common sense.
If denormalizating it takes 0,03 s and without denormalizating takes 2s
without taking in count that it increase 10x the amount of block read, etc.
..and this is a process t hat run 1000's of time a day, don't denormalizing
is a mistake.
..but if this process is run few times a day, denormalizing is a mistake.

4th and 5th normalization is not always advisable, all depends.
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to:  oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------


The information contained in this communication, 
including attachments, is strictly confidential 
and for the intended use of the addressee only; 
it may also contain proprietary, price sensitive, 
or legally privileged information. Notice is hereby 
given that any disclosure, distribution, dissemination, 
use, or copying of the information by anyone other 
than the intended recipient is strictly prohibited 
and may be illegal. If you have received this communication 
in error, please notify the sender immediately by 
reply e-mail, delete this communication, and destroy 
all copies.

Corporate Systems, Inc. has taken reasonable precautions 
to ensure that any attachment to this e-mail has been 
swept for viruses. We specifically disclaim all liability 
and will accept no responsibility for damage sustained 
as a result of software viruses and advise you to carry 
out your own virus checks before opening any attachment.

----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to:  oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------

Other related posts: