boblarson
Smeghead
- Local time
- Today, 13:16
- Joined
- Jan 12, 2001
- Messages
- 32,059
Ok, but why is that?
If you have a group of "things" (such as fees) then you should have them in their own table so you can combine them with another table (clients) that way?
Okay, let's visit something. A fee is an item, correct? It is no more different than say, an apple. There are many types of apples and each type of apple may have a different price associated with it and you could, as a seller of apples sell your apples to different people at different prices depending on who they are. So what makes a fee any different? You have a FEE. That is the Item. You have different types of fees and different prices based on the clients. Those should be added to the customer as a row in a junction table along with the price of the fee.
Can you predict, with accuracy, that a new fee will never be added? No, not likely. As such it should be based on adding a ROW of data not a column. If you add a column then EVERYTHING (queries, forms, reports, etc.) will need to change, correct?
If you have a new fee and you've set this up in a properly normalized fashion - then you can just add a new fee (ROW) to the fees table, add a ROW to the client/fees table which identifies which fees a client has and how much the fee is.
Then your queries need no "fixing" and your form needs nothing added, and your reports likely need no changes.
proper normalization of data does wonders for adding information that was not known to be needed in the future (or not needed as the case may be).