RE: Normalization
- From: "Mercadante, Thomas F" <thomas.mercadante@xxxxxxxxxxxxxxxxx>
- To: "'oracle-l@xxxxxxxxxxxxx'" <oracle-l@xxxxxxxxxxxxx>
- Date: Thu, 29 Jul 2004 13:00:21 -0400
I disagree with the answer. I believe that normalization is still the key
for an efficient running database. With things like snapshots and
materialized views, reducing sql joins is no longer an issue. And a well
designed datababase supports well designed joins.
But I do agree with your statement that good db design is being ignored.
All you have to do is to look at *any* of the flickin ERP databases that are
being produced today. They break so many rules it ain't even funny. My
guess is that the battle between produce/sell it and design it right is
tipped to the sell it side.
Tom Mercadante
Oracle Certified Professional
-----Original Message-----
From: Paul Baumgartel [mailto:treegarden@xxxxxxxxx]
Sent: Thursday, July 29, 2004 11:32 AM
To: oracle-l@xxxxxxxxxxxxx
Subject: Normalization
I'd love to hear comments on the following Q&A (by a well-known Oracle
"expert"). Do list members think that this view prevails today? Am I
correct in believing that the importance of normalization, and the reasons
for that importance, are given short shrift by many DB designers?
Q: What are the basic guidelines one should keep in mind while designing a
database? Is denormalization always good?
A: I used to teach database design in graduate school, and your question is
excellent! The main purpose of high normalization was the reduction of disk
space, back when it mattered in the 1970s.
Today, I always introduce redundancy into the model whenever it can
eliminate an SQL join, but not always. I make my decision based on two
criteria:
1 - The size of the redundant item
2 - The volatility of the item (e.g. how often do I need to duplicate
updates)
=====
Paul Baumgartel
Transcentive, Inc.
www.transcentive.com
__________________________________
Do you Yahoo!?
Yahoo! Mail - You care about security. So do we.
http://promotions.yahoo.com/new_mail
----------------------------------------------------------------
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
-----------------------------------------------------------------
----------------------------------------------------------------
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:
