Doug,

The question is (except perhaps in extreme academic circles) is not whether to denormalize or not - but how much to denormalize. I'd bet that few or none of the UTers have EVER worked on a completely normalized database of any significant size.

Let me ask you - do you have a "customer" or "employee"table with a "first name" field in it? Do you have more than one person in it with the first name of Bob or John or Mary? Do you have a separate table of just first names with an fkey from the customer or employee table to the "firstname" table? Probably not huh? Well- you're denormalized.

Second - do you have any tables with fields that are left empty because the info doesn't apply to the particular record i.e. - an "address line 2" field that isn't used for many records? Well - if you don't have "address line 2" off in a separate table - you're denormalized

Are you telling me that you have no calculated totals stored anywhere - whether aggregate or atomically calculated? If you do - you're denormalized.

So why don't we have separate fields for first names and adrsess line 2, etc? Simple because it would make design unduly complex and run-time perfomance sluggish. And for these SAME REASONS, it SOMETIMES makes sense to denormalize further in a limited and controlled fashion. And my argument is, that it not only makes sense, but is the RIGHT thing to do to have good database design in those cases.

Happy Y2K!
Ken


>Ken,
>
>If I "denormalize" I try very hard to do so into temporary files. I really resist doing that to my primary tables.
>
>Maybe a VIEW would be a better place to start for something like what you're suggesting? That way you can make it as ugly as you want *g* and you don't goof up your basic data set.
>
>Best,
>
>DD
>
>>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
>>
>>
>>
>>>>But SQL is slow - why normalize if you SQL?
>>>
>>>Why use a relational database if you don't normalize?