Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Help please - normalization question
Message
From
05/07/2001 17:38:29
 
 
To
05/07/2001 16:33:25
General information
Forum:
Visual FoxPro
Category:
Databases,Tables, Views, Indexing and SQL syntax
Miscellaneous
Thread ID:
00527186
Message ID:
00527227
Views:
28
Alejandro,

Any time I've read on this topic there invariably is a statement that 'there are situations where, for practical purposes, one may deliberately break the third normal form'.

I think that the key here is to be very careful with the circumstances (the "practical purposes"). For instance, just because something might be summed again and again is probably not good enough reason in and of itself. If, however, the calculations involved (summing) regularly involved hundreds of thousands (or more) records and thus would take a long time EVERY TIME then I think you have a "practical purpose". I would consider an A/R Aged-Analysis table to be such a thing (when a large A/R table is involved).

I am generally not a fan of keeping total fields or sub-total fields 'as a matter of course' in my database designs. When I tried this in an earlier life I found that there were instances when the totals no longer matched. Better to recalculate than to have an incorrect number.

Hillmar mentioned 5th form. Again from memory it seems that when there is more than 1 table involved (as is your case) then it (5th) may be applicable. Not that I think you should go there by any means.

Good luck,

JimN

>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
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform