|< Day Day Up >|
Miscellaneous DDL Guidelines
This section contains guidelines that are not easily categorized. They provide SQL guidance from an overall perspective of DB2 development.
Avoid Using DDL in an Application Program
Do not issue DDL from an application program. DDL statements should be planned by a database administrator and issued when they cause the least disruption to the production system.
statements are used, DB2 must update its system catalog tables. These statements also place a lock on the database DBD being affected by the DDL. This can affect the overall performance of the DB2 system. When DDL is issued from an application program, DB2 object creation is difficult to control and schedule
It is okay to use declared temporary tables in your programs, because executing a DECLARE for a temporary table does not require DB2 to access the system catalog.
Plan the Execution of DDL
Because of the potential impact on the application system (such as locking, new functionality, or new access paths), schedule the execution of DDL statements during off-peak hours.
Strive for Relational Purity
Learn and understand the relational model and let your design decisions be influenced by it. Assume that DB2 eventually will support all features of the relational model and plan
Favor Normalized Tables
Taking all the previous suggestions into account, avoid denormalization unless performance reasons
Maintain Standard Libraries
Create standard libraries for
parameters, utility JCL, utility parameters, VSAM
delete and define parameters for
To maintain these libraries, ensure that all
Adhere to the
|< Day Day Up >|