I think one of the first things you have to do is distinguish between issues of data integrity, consistiency, etc and issues of reporting. The goals of normalization are to reduce redundancy and encourage consistiency. All of this is at odds with reporting requirements which tends to make use of lots of summary values and calucations.

Often, calculating the values on the fly is not a problem. However, at some point, performance starts to take a hit to the degree that waiting for the report to generate is a waste of time.

So, do you violate rules of normalization for the purpose of reporting? If your online data entry tasks don't get hampered as a result, why not? It could be argued that in reality, you are not violating the 3rd normal form since these summary values are distinct data entities. I do this sort of thing all of the time.

Adhering to any rule independent of the facts of the situation can get you in trouble. Often, it makes sense sense to deviate from the rules.




>Please tell what you people do:
>
>I understand that:
>1) The 3rd normal form is the ideal way to designing a database.
>2) One of the requirements of 3rd normal form is that no fields contain redundant information. This in turn means no field should exist which can be calculated by summing values from a child table.
>
>I find two problems with this:
>1) Considerable time is spent summing the same data again and again.
>2) There is no easy and efficient way (with SQL) of obtaining a single record for each transaction that shows the total of each summary category. This of course is needed to create effective reports.
>
>Consider our situation: Our transactions can contain 100 different kinds of income, which can be subdivided into ten summary categories on which most reports are based. Is there something inherently wrong with creating a field in the transaction table for each of the summary categories?
>
>What do the purists say? What do you people do in reality?
>
>TIA,
>
>Alex