>Nancy,
>
>PMFJI -
>
>I denormalize in a limited amount - primarily for performance reasons on searches, reports, etc. Too much normalization can make a system uneccessarily complex and sluggish - both in development and for users - I know - I've been there. As developers, we need to concentrate more on user practicalities than holy grails of database academia.
>
>Again - the thought that "Noramlization is the way it has to be always" is one of those "truths" that are espoused without any true justification. In fact - I submit that for many - if not most - systems, a designer who does NOT implement strategic denormalization doesn't know what they are doing.
>

Ken,

There is no such thing as "too much normalization" either a design is normalized or it is not. Normalization is not a "holy grail" as you have said, however it is an invaluable tool towards eliminating potential design problems in the database early in the development process.

Also, your "acedemia" reference is tiersome to me. Relational database design is based on relational algebra which is a field of mathematics. Mathematics is an exact science. In RDB there are correct and incorrect wasy of doing things. The procee of normalization exists to minimize or eliminate problems with updates, inserts, and deletes. Normalization does not address data retreival adn sometimes the exact design that works best for updates is wrong for rereival. That is when denormalization is indicated.

There is a major problem with denormalization though, and that is that it is sometimes useful. Why is that a problem? Because denormalization becomes an excuse for never normalizing the design in the first place. That's why my mantra on denormalization is this;

"If you know what the fully normalized design is, and you know exactly which normal form you are about to violate, and you know why that normal form exists, and you know the exact benefits you will abtain from denormalizing, you know what the consequence of violating that normal form are, then by all means denormalize. If you are unsure of any one of these thigns, then seek advice from someone who knows more about relational data design."