Re: Normalizing vs. Denormalizing

From: Joel Garry <joelga_at_rossinc.com>
Date: 1996/04/18
Message-ID: <1996Apr18.183332.8614_at_rossinc.com>#1/1


In article <4km5s7$4pl_at_maverick.tad.eds.com> bob_at_latcost1.alaao.ats.eds.com (Bob Stewart) writes:
>Shariq Mansoor (opto2y_at_menudo.uh.edu) wrote:
>: There are several performance techniques you can use to improve the
>: performance of your system including caching schemes, indexing, fast
>: disk access, SGA, and shared_pool.....etc. By denormalization you are
>: really defeating the purpose of relational database. Remember that once
>: you develop a system it is not EASY to make changes later. Remember you
>: are not just storing DATA but translting your way of doing business and
>: rules into an information system, and if your system is not normalize,
>: you won't be able to utilize the new concepts (Data mining, Data
>: warehousing....etc.) to there full potential. This means that you have
>
>I think that you'll find that normalizing is detrimental to running
>a Data Warehouse.
>
>: to spend time and effort down the road (probably very soon)on your existing
>: system. RDMS such as Oracle are designed to handle normalization very
>: well even with the basic configuration and with a help of a good DBA you
>: can design a 3rd or even 4th deg. normalize system without any significant
>: performance problem. Consider demormalization only when the performance
>
>Bull. Accepting an answer like this requires little thought from the
>acceptor, of course. Unfortunately, as a result, little thought will have
>gone into the use for which the database is being designed. Normalizing
>just because "it's what you should do" is really stupid. I wouldn't make
>my design decisions based on what Oracle (et al) are supposed to do, but
>rather on what use my customers will be putting their data to.

Try learning some relational theory to find out why it's what you should do. Then remember, it's for the logical design, once that is out of the way then you can denormalize for the physical design. But just throwing everything together in each record is definitely bad design. Or do you have some other kind of design methodology that is superior for relational databases in data warehouses? Or are you just taking the existing data and storing it, not admitting that that is implicitly following the design the original data was in?

>
>Asbestos suit is now on!

I hope your customers don't decide to change the use their data will be put to. Can't say as I've seen too many successful companies be that static over time. If they are, they might as well stick with the CODASYL. Harumph.

>--
>Bob Stewart ASE
>(310) 335-7152 Air Transportation Division
>bob_at_latcost1.alaao.ats.eds.com
>
>I am definitely NOT speaking for EDS.

-- 
Joel Garry               joelga_at_rossinc.com               Compuserve 70661,1534
These are my opinions, not necessarily those of Ross Systems, Inc.   <> <>
%DCL-W-SOFTONEDGEDONTPUSH, Software On Edge - Don't Push.            \ V /
panic: ifree: freeing free inodes...                                   O
Received on Thu Apr 18 1996 - 00:00:00 CEST

Original text of this message