Re: normalisation vs denormalisation

Amin Adatia wrote:
>
> I was only pulling your leg about the early delivery time ! <s> I think,
> as you do I think, poor design is the larger pitfall to early delivery.
>
> What bothers me is that for the past few years hardware has been
> relatively cheaper *but* the developers or rather their managers have
> been ignoring the fact that people are more expensive. A 12 month
> project can afford to wait for the better performing hardware and keep
> the design "clean". A lot of the reasons for making a mess of the design
> is the "performance" argument. A lot of the time extra RAM and/or disk
> will solve the performance. It is not an everyday application that need
> nano-second response *and* not every application is the ATM class.
>
> Regards

Hardware performance, in most cases is a fine solution. Where I work we are embeding our database into machine that we will be selling. In this environment, the processors you can run your database on are generally not the fastes machines on the market. Dispite this we have gotten decent performance out of a mainly normalized database. The key to this is how we access the database. By spending time optimizing our data access routines, SQL, etc. our design works fairly well and efficiently. We have had to do some things which are not normalized, but all instances of this was copying a field from one table to another so we would not have to take the preformance hit to join with that table. To ensure integrity of the data, these copied fields are considered read only, and I have written triggers on the tables which contain the official copy of the data to keep the fields up to date in other tables.

Eric Mortensen
mortense_at_cibadiag.com Received on Tue Aug 13 1996 - 00:00:00 CEST