|
|
|
|
|
Providing documentation for your
databases is absolutely vital. This allows subsequent modifications to be made
without causing an unforeseen impact on the current applications. One of the most
important is the documentation of your triggers. This gives someone a very good
idea of the interaction that are occurring within any given trigger. All database objects placed in the production environment shall be documented in the following database documentation section. The documentation shall contain a high level overview of the object created and shall be added to the appropriate section of the documentation. Any additions, deletions, or modifications to existing documentation shall be noted in Appendix A. Documentation shall be created as follows: Tables Table documentation shall consist of the table name and a short description of the purpose of the table. It shall also contain a listing of all columns in the table with a short description of the purpose of the column. Indexes Index documentation shall be grouped by table. The documentation will list the index name, type of index, purpose of the index if not already explained by the type of index, and the columns that make up the index. An index type of primary key is self explanatory. An index on a column to improve query performance needs to be documented. In these cases, the application that needed the index and the application component that needed the index need to be documented. This is done to help in maintenance. If the application or component that needed an index is eliminated, the index can be removed from the database. Triggers Trigger documentation shall be grouped by table. A high level overview of the trigger shall be given. This overview shall include any objects that are modified by the trigger and shall be carried across the hierarchy in the case of nested triggers. Any nested triggers that are fired shall be set off in bold face to make them easy to distinguish from the rest of the code. If a trigger was created or code was added to an existing trigger for application requirements, the name of the application and the component that required the code shall be noted. This is done to help in maintenance. If the application or component that needed trigger code is eliminated, the trigger code can be removed from the database. Example: Update table1 1. Does some processing on column1 2. Does some processing on column10 in table2 3. Fires update trigger table2 A. Does some processing B. Inserts a row into table3 1. Fires insert trigger on table3 (Note the use of bold face type. This allows someone to easily pick out the most important aspects of the trigger interactions.) You can download a sample of the trigger documentation that I have done in Word format. Defaults Default documentation will list the name of the default, the default value, and the column / user datatype the default is bound to. It shall also list the name of the table where the column is located. Rules Rule documentation shall list the table name, rule description, the column / user datatype the rule is bound to, and the purpose of the rule. |
All content on this site, except where noted, represents an original work of Michael R. Hotek and is protected by applicable copyright laws. The SQL Server FAQ is the sole work of Neil Pike. No page, portion of a page, or download may be used for commercial purposes in whole or in part without the express, written permission of the applicable author.