Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!ames!ptsfa!hippo!eric
From: eric@hippo.UUCP
Newsgroups: comp.databases
Subject: Re: Normalized Databases
Message-ID: <107@hippo.UUCP>
Date: Thu, 2-Apr-87 17:44:46 EST
Article-I.D.: hippo.107
Posted: Thu Apr  2 17:44:46 1987
Date-Received: Sat, 4-Apr-87 17:21:35 EST
References: <43239@beno.seismo.CSS.GOV>
Distribution: na
Organization: HEALTHCARE 2000
Lines: 25
Keywords: normal form, relational


	Higher normal forms are good, but only in a perfect world. It is
true that it will take less disk space (since any data item will only
be stored once), and the inherent design of the database is "cleaner".
It also makes updates easier, since the only replicated data are key
values.

	What they are not telling you is that the penalty can be performance.
Third normal form databases can quickly lead you to multi-table joins
instead of simple retrieves out of a single table.

	Being the veteran of several projects that used relational databases
(sometimes quite large and complex), I can tell you that our usual
strategy is to design the database initially to third normal form
(using ER diagrams, or whatever), and then start looking at where the
bottlenecks might be, and where replication might be in order to achieve
the necessary performance. But it is alot better to start in third normal
form and work backwards (at least then you understand and document why
you replicated a particular set of data), then to just shoot for a lower
order of normalization to start with. 

-- 

					eric
					...!ptsfa!hippo!eric