Re: Discuss Data Design

Hi Steve.

I agree with you that there are severe trade-offs that should be considered before denormalizg tables. However, in my experiences I have often found many occassions where denormalization is necessary. Not only for decision support applications but also for update transactions (eg., to eliminate I/Os). A obvious example is zipcodes which is an example of defacto denormalization in most systems (zipcodes are stored redundantly in addresses in order to minimize I/Os). There are many other examples such as names which are often stored redundantly in order to minimize table look-us. There definitely are problems with redundant data but often necessary in order to achieve required performance characteristics - particularly in high transaction environments.

Regards,

Rich

In article <3flv2a$d4t$1_at_mhadf.production.compuserve.com> Steve Edelstein <74160.645_at_CompuServe.COM> writes:>From: Steve Edelstein <74160.645_at_CompuServe.COM>>Subject: Re: Discuss Data Design
>Date: 19 Jan 1995 15:04:42 GMT
 

>Don't de-normalize to cut down on join loads. It makes the
>database hard to maintain/enhance. Joins are optimized by using
>indexes correctly. There should never be a problem with joins if
>they're done correctly! In fact, there's really NEVER a reason to
>de-normalize. It makes your life harder in the long term (altho
>it may seem easier short term). The idea of normalized data is
>central to relational databases. It separates them from the
>hierarchical ones, and means you can use the db and its tools as
>they were intended.
 

>I think its better to have one large table (with views for each
>year, for instance). This is also a matter of maintenance ease as
>well as processing efficiency. This may ba a personal preference,
> and there may be arguments about it (but NOT about
>normalization!).
 

>Hope this helps.
 

>--
>Steve Edelstein VOICE: 212-956-3670
>Relational Business Systems CompuServe: 74160,645
>124 West 60th Street Suite 47C Author of
>New York, NY 10023 "Learning Oracle Forms"

Richard Finkelstein
Performance Computing, Inc.
312-549-8325 (Voice)
312-549-4824 (Fax) Received on Sat Jan 21 1995 - 10:09:32 CET