Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!bionet!apple!mrspoc!itkin
From: itkin@mrspoc.Transact.COM (Steven M. List)
Newsgroups: comp.databases
Subject: Re: Do you normalize?
Summary: Sometimes it just doesn't make sense
Keywords: normalization
Message-ID: <1989Jul20.210213.22208@mrspoc.Transact.COM>
Date: 20 Jul 89 21:02:13 GMT
References: <242@6sigma.UUCP> <3665@fp.sei.cmu.edu>
Reply-To: itkin@guinan.Transact.COM (Steven List)
Organization: Transact Software, Inc.
Lines: 26

In article <3665@fp.sei.cmu.edu> dmc@sei.cmu.edu (Dawn Cappelli) writes:
> 
> After the e-r diagram is completed, I then design the tables.  As I design
> the tables, I no longer consciously normalize the data, however, 
> normalization is an intuitive process at this point for me.  In addition,
> I sometimes make a conscious decision to denormalize tables in order to 
> enhance performance.
> 
Bravo, Dawn!  Dawn's was the only response that I saw that made what, to
me, is a reasonable statement about denormalization (is that a word?).
I have found, in designing applications AND databases (and they DO usually
go together), that sometimes normalization is a significant detriment to
performance.

When retrieving data for reporting purposes, the trade-off between such
things as normalization and speed of retrieval can be a significant design
issue.  While normalization is an excellent concept, it is not sufficient
in and of itself.  It is a concept that is a tool to designing "better"
applications.  Where it obstructs rather than improves the process, it
is better ignored.
-- 
 +----------------------------------------------------------------------------+
 :                Steven List @ Transact Software, Inc. :^>~                  :
 :           Chairman, Unify User Group of Northern California                :
 :     {apple,coherent,limbo,mips,pyramid,ubvax}!itkin@guinan.Transact.COM    :