>It's late, and I need a break, so...
>
>Can data be 'over' normalized? As I'm sitting here trying to decipher the 20 to 30 nearly perfectly normalized related tables in this program, I'm seriously starting to question how much is too much. The data manipulation at our disposal with well normalized tables is phenomenal, but at what cost? Is there a limit to the complexity of relations the mind can accurately maintain? Are there any rules of thumb as to what that is? This then begs the question of how best to denormalize certain data.
>
>I was just looking at the VFP SCX structure for kicks (yep, that's what they call fun out here in the boonies). It seems awfully de-normalized to me. I would think each class library should consist of several tables, not just one. Shouldn't they consist of a class table, and perhaps a properties table, a methods table, etc.? Why does the company that develops this database system not take advantage of this normalization capability?


Hi David,

I actually believe data can be over-normalized, as I am facing a similar situation. I have read elsewhere that most database designs can get by on 3rd normal form, without going further than this. I would have to look up the rules to be sure, but basically adding certain types of 'join tables' is part of 4th normal form.

In my own system, I am finding the task of pulling together enough information to present the users with reasonably complete data entry screens requires several joins at several levels of the design.

We are in the property tax business, and so the 'main' property file has about 8 foreign key relations branching out of it for various other pieces of information you may need, such as:

the client it belongs to,
the state and county it is in,
the ownership table holding different owners and their percentage ownerships
who the taxing authorities are who want to bleed money from the owners
whether or not they have been paid for this year
and more...

The data entry clerks who add information to this system do this from one point of entry, so just pulling it together can be a chore.

At the same time, referential integrity issues arise when redundant data exists in tables, and a raft of these types of problems in a poorly designed current system is the motivation for the new one under construction now. :)

I have to agree with an earlier post suggesting full normalization be done before considering backing off from it, as it will become apparent what the price of backing off is, giving you a heads-up to what you will be facing.
Just my 2 cents.