>>Back in the dark ages of dBase, I learned the hard way of designing a database schema that honors atleast the first 3 normal forms. The first, second, and third normal form of database design has long since become second nature. But I came home home from work today and resurrected an old text book and revisited my old friend - "The Boyce/Codd definition of Normalization". I was looking for some reference as to reasons why you would not follow first 3 normal forms. Little surprise my old textbook turned up nothing :)
>>
>>But now I'm curious. I've been in a situation where I broke the 3rd normal form on purpose and for the sake of duplicating data to increase speed/performance (Data Warehousing App). In that situation I never regretted it, it got the job done despite how hard it was to maintain over time. Anybody else ever have another darn good reason (with no regrets afterwards) for not honoring the first 3 normal forms of database design? TIA!!
>
>I do not follow normalization for invoicing. I duplicate the product description in my invoice LineItems table along with the Item Number. True normalization would only require the inclusion of the item number. However, for historical reasons, I must include the Item description as it was at the time of the sale, same thing for the unit price and size (also duplicated in the LineItems table). I can not rely on item descriptions and unit prices remaining constant.
>
>I also duplicate the sales tax rate in my Invoice table. I have a SalesTax table of current rates, but because they change, I have to have a SalesTax field (2 actually -- an additional one for the Non-Taxable items rate [which is not always 0%. Louisiana actually charges 4% State on tax exempt items]).
>
>In some instances, you would need to repeat people's names in tables other than the Customer, Census, Employee, etc., table if a historical need of name changes (marriage, divorce, religious conversions, NBA players, etc) is necessary.

The duplication of Sales Tax rate in Invoice table can be avoided. Give a Unique name to the type of taxation and assing the percentage in a seperate table. Once an Invoice is raised, for that Tax structure, its percentages CANNOT be modified. By this design you can just store the Tax id of tax table in Invoice table