Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!ucbvax!pasteur!postgres!larry
From: larry@postgres.uucp (Larry Rowe)
Newsgroups: comp.databases
Subject: Re: Recent postings to comp.databases...
Message-ID: <16020@pasteur.Berkeley.EDU>
Date: 3 Aug 89 18:01:50 GMT
References: <15963@pasteur.Berkeley.EDU> <450@cimshop.UUCP>
Sender: news@pasteur.Berkeley.EDU
Reply-To: larry@postgres.UUCP (Larry Rowe)
Organization: Postgres Research Group, UC Berkeley
Lines: 27

In article <450@cimshop.UUCP> davidm@cimshop.UUCP (David Masterson) writes:
>>2) normalization
>>donovan hsieh had it right when he said that you have to pay attention
>>to both consistency *and* performance.  i have seen too many people fail
	...
>Would you say, though, that it is more appropriate to start with a database
>that well constructed (ie. normalized) and work toward an efficient design or
>vice versa?  This, of course, assumes that a person is willing to "wreck" his
>well built database for the lowly consideration of performance.  ;-)

my advice would be to do a good logical database design.  personally, i
don't do normalization per se.  i use an entity-relationship modelling
technique which insures a normalized designed (3NF).  then, examine your
xacts and estimate their performance.  if you can't estimate them, prototype
your database and do a pilot study.  if the performance is acceptable,
you're done.  otherwise, denormalize your design to fix the performance
problems.  usually, the problems arise because you're doing costly joins
in time-critical xacts.  the obvious solution is to store the join rather
than the projections.

unfortunately, you may end up with a strange database design.  this problem
can be solved sometimes by adding more hardware or by building snapshots
(i.e., copies) of critical tables and denormalizing them. 

the bottom line is that you must build an application that works and that
relational dbms's, like most technology, can help but it is not perfect.
	larry