Normalization (was RE: Large databases)

> -----Original Message-----
> From: Lyndon Tiu [mailto:ltiu_at_alumni.sfu.ca]
> Sent: Wednesday, April 16, 2003 4:19 PM
> To: Multiple recipients of list ORACLE-L
> Subject: RE: Large databases
>
>
> Question to all you practical DBA's out there: Is is slower or faster
> to normalize or not?
>

Heck, I'll give the fire and brimstone answer (sometimes my feed from the list seems delayed, so I apologize for the long email, if it turns out to be redundant).

Is it slower or faster to clean up a database that has corrupted data because of insert, delete, and update anomalies or not?

Is it slower or faster to reinvent RI in the application rather than having the database take care of it?

The reason for normalization is that SQL is based on set theoretical principles, and nonnormalized tables lead to bad data. A fully normalized database guarantees that certain levels of consistency are met. A nonnormalized database means those levels of consistency can't be guaranteed. End of story.

But "normalized", as several have already mentioned, means "meets the business requirements". There's no such thing as an inherently normalized database - it depends on the data requirements.

I'll leave a little loophole here, by stressing 'nonnormalized' versus 'denormalized'. If you have a well-designed, normalized database, and performance on some critical query sucks, and you can't tune it to go fast enough, and denormalization saves the company, then knock yourself out.

Chris (living in a dream world - none of what I said above applies in the stuff I have to rubber-stamp for our apps because of time constraints or general d*veloper/manager cussedness).

LEGAL NOTICE:
Unless expressly stated otherwise, this message is confidential and may be privileged. It is intended for the addressee(s) only. Access to this e-mail by anyone else is unauthorized. If you are not an addressee, any disclosure or copying of the contents or any action taken (or not taken) in reliance on it is unauthorized and may be unlawful. If you are not an addressee, please inform the sender immediately.

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Sarnowski, Chris
  INET: csarnows_at_CuraGen.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).