RE: Large databases

Normalization is not relative. It is very strictly defined.

Almost all "tests" of non-normalization are done not because normalization failed but because there was a short-circuit in the design and implementation process. The requirements were not clearly defined (so no basis for normalization) or the analysis was not completed. Sometimes there are legitimate reasons for this short-circuit (prototypes, throw-away systems, etc). But some prototypes and throw-away systems turn out to be very sticky.

In some cases, the short-circuit in the design process is caused by a stickler who thinks that a heuristic like "only 4 columns" is a suitable replacement for the hard work of collecting and analyzing requirements. Sometimes it may be (seems unlikely). But that process is not normalization.

You can have too many tables or too few tables. You can't have a database that is "too normalized". It either is or it isn't. As you point out, it is necessary to specify which form (1,2,3,BC,4,5, etc) you are talking about.

If the argument is that a well-designed system is guaranteed to fall into disrepair, and thus become harder to maintain, so you may as well not design it in the first place (you'll save time and still have a system that is hard to maintain), well, that is a point of view.

But don't pretend, as so many cowboy coders do, that the poorly designed system is actually easier to maintain. If you think so, you've never tried to maintain another cowboy's code (if you are a cowboy, you tossed their code and rewrote everything anyway, because you think you're the only one with a clue).

I promise I won't post in public on this thread again. Private posts will be read.

> -----Original Message-----
> From: Lyndon Tiu [mailto:ltiu_at_alumni.sfu.ca]
> Sent: Friday, April 18, 2003 2:52 PM
> To: Multiple recipients of list ORACLE-L
> Subject: RE: Large databases
>
>
> Normalization is relative. Depends who you talk to and what you are
> trying to do. Normalization is necessary but only up to a point.
>
> When you said the normalized database performed faster, how do you
> know it will perform slower if not normalized, did you test it?
>
> Also, Normalization is not a one step process, you can normalize up to
> first normal form only or second normal form only.
>
> After designing my database, the first thing the Access DBA said was:
> "I have a book about designing databases and a chapter about
> normalization. You should read it." and then he showed me his ER
> Diagram with neat little 4 column tables. The funny thing is, the
> tables have 4 columns not because of normalization but because he
> would only put a max of 4 columns worth of information in a
> table. As in:
>
>

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).