Database Design for Mere Mortals: A Hands-On Guide to Relational Database Design

Documenting Your Actions

If you've exhausted all other options and still come to the conclusion that you need to bend or break the rules, then you must document each rule you break and each action you take! It is important that you document your changes because doing so will compel you to think about the consequences of what you are about to do and it provides a means of recording the changes you make to the database structure. Should you decide later that the modifications did not provide a significant increase in processing performance, you can use the documentation as a guide to reverse the modifications you initially made.

These are the items that you should record:

• The reason you're breaking the rules. Increasing processing performance and decreasing the time it takes to print complex reports are two of the most common reasons for breaking the rules. Whatever your reason, be sure to state it thoroughly and clearly.

• The design principle you're violating. Recording how you've altered the database design will give you the means to reverse these changes later should you determine that performance did not significantly improve. You might indicate that you're altering the structure of a table, for example.

• The aspect of the database that you're modifying. Indicate which particular field, table, relationship, or view you are going to alter. Once again, this information will be valuable should you decide to reverse the modifications.

• The specific modifications you are making. Once you determine which item you need to modify, record the exact modifications you make to that item. For example, if you need to modify a relationship, note the exact changes you make to its characteristics.

• The anticipated effects on the database and the application program. Any modifications you make to the database are going to affect all accompanying end- user application programs. For example, altering the structure of a particular table can affect data integrity, view structures, data-entry forms and reports built upon the table (either partially or totally), and macros or programming code that refer to the table. You must be sure to list every effect.

Add this document to the documentation you compiled for the database. Even if you reverse the changes later, this record could prevent you from yielding to a future impulse to attempt the same types of changes.