RE: Normalization

From: Mercadante, Thomas F <thomas.mercadante_at_labor.state.ny.us>
Date: Thu, 29 Jul 2004 13:00:21 -0400
Message-ID: <DE8A21F8F1D0254EA4A9214D52AB2FED11F2C002@exchsen0a1ma>

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_at_yahoo.com] Sent: Thursday, July 29, 2004 11:32 AM
To: oracle-l_at_freelists.org
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?

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_at_freelists.org put 'unsubscribe' in the subject line.
--

Archives are at http://www.freelists.org/archives/oracle-l/

FAQ is at http://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_at_freelists.org

put 'unsubscribe' in the subject line.
--

Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html

Received on Thu Jul 29 2004 - 11:57:14 CDT