Sometimes we may need to denormalize a database.
In the book "Access 97 Developer's Handbook" Third Edition (SYBEX), the authors, when teaching Database Design, laid down some guidelines on breaking the rules of normalization.
<Quote>
Breaking the Rules: When to Denormalize
Sometimes it's necessary to break the rules of normalization and create a database that is deliberately less normal than Third Normal Form. You'll usually do this for performance reasons or because the users of the database demand it. While this won't get you any points with database design purists, ultimately you have to deliver a solution that satisfies your users. If you do decide to break the rules and denormalize your database, however, it's important that you follow these guidelines:
- Break the rules deliberately; have a good reason for denormalizing.
- Be fully aware of the trade-offs this decision entails.
- Thoroughly document your decision.
- Create the necessary application adjustments to avoid anomalies.
[The authors gave two scenarios:]
- You decide to store an indexed computed column, Soundex, in tblCustomer to improve query performance, in violation of 3NF (because Soundex is dependent on LastName).
- To improve report performance, you decide to create a column named TotalOrderCost that contains a sum of the cost of each order item in tblOrder. This violates 2NF because TotalOrderCost is not dependent on the primary key of the table. ...... Since you often create reports that need to include the total order cost but not the cost of individual items, you break 2NF to avoid having to join these two tables every time this report needs to be generated.
<End quote>
The second scenario demonstrated the need of storing a calculated field in a table, though in violation of relational database design. I wonder what "James Romborough" would say about this.
I had assumed in this case that column 1 was an autonumber
