Re: To Denormalise or not to Denormalise

Well.. not ~completely normalized~ but darn near...

I find it rare (very rare even) that I need to denormalize. Lets say you have 50 - 60 tables - a smallish system... Each having 10 or less columns (a personal rule of mine is more than 10 columns then you made a mistake) You could expect maybe one redundant column.. maybe two. not much denormalization here...

my 2 cents
randy

Van Messner wrote:

> Your friend, the theorist, wouldn't get very far in the day-to-day usage of
> his database. In fact it would be interesting to see if anyone here is
> working with, or has ever worked with, a moderate-sized database (say 20G or
> more) that is completely normalized. I've never seen one.
>
> Van
>
> Brian Peasland <peasland_at_edcmail.cr.usgs.gov> wrote in message
> news:3906E5CB.874B3579_at_edcmail.cr.usgs.gov...
> > I don't want to repeat any of the previous replies. They all have good
> > points. I do want to add that one can think of clustered tables as sort
> > of denormalizing two tables. Oracle added this feature to help improve
> > performance under certain conditions. Although in my opinion, you could
> > just denormalize two table and do away with the cluster structure.
> >
> > HTH,
> > Brian
> >
> > Billy Verreynne wrote:
> > >
> > > "Lawrence" <lsimela_at_mahalini.prestel.co.uk> wrote:
> > >
> > > >I wonder if any of you folk out there can help settle an argument with
 a
> > > >colleague who passionately believes that one should never have to
> > > >denormalise any part of a well designed database. He believes that a
 'well
> > > >designed' database should be in 3NF or higher and can be efficiently
> > > >implemented without denormalising any part of it.
> > >
> > > That entirely depends on the nature of the database. Implementing 3NF
> > > for a datamart or data warehouse is commiting performance suicide.
> > >
> > > Back in the 80's design methodologies were quite the topic. One of
> > > these were called Tetrach. The primary purpose was to gather enough
> > > data during the analysis and design phases, in order to simulate
> > > performance loads using a maths model. Was interesting back then, as
> > > in once case study (part of the advance course in Tetrach A&D) showed
> > > that how implementing an invoice in 3NF could cause a business to fail
> > > to process a single day's average load of orders (given the existing
> > > hardware platform used by the business). Denormalising the invoice
> > > solved this performance problem and potentially saved the company from
> > > not being able to fill the orders, or spend a lot of money of a very
> > > expensive hardware upgrade. Of course, back then we measured memory in
> > > KB and not MB or even GB.. :-)
> > >
> > > I am not sure what the argument is with your friend though. A well
> > > designed database in 3NF is a well designed database if the aim is to
> > > create a relational database. No question about that. However, that is
> > > only one slice of the pie that makes up a corporate system. From a
> > > theoretical point of view, you can view that slice in isoltaion. From
> > > a real word business view, you simply can not. A well designed
> > > database means nothing the business if it can not deliver - no matter
> > > how good or tasty that single slice is, it is the whole pie that is
> > > consumed by the business.
> > >
> > > regards,
> > > Billy
> >
> > --
> > ========================================
> > Brian Peasland
> > Raytheons Systems at
> > USGS EROS Data Center
> > These opinions are my own and do not
> > necessarily reflect the opinions of my
> > company!
> > ========================================
Received on Tue May 02 2000 - 00:00:00 CDT