|
|
When the programming stage hits, many teams breath a sigh of relief, relax, and gaze in awe at the completed physical database which came out of the design phase. "Thank goodness we don't have to worry about this anymore", is heard quite often. "Now that the database is finished, forget about it and let's start coding!" is another familiar comment. Fortunately, in a tremendous number of situations (given that rigorous database access analysis was performed during the creation of program specifications), all of the required database indexes have already been identified, built, and are ready for use! If the system is fairly straightforward, the databases and their related indexes may never be have to be modified. But if the system is large and complex, the odds are that the programming team will find additional data access requirements which will require the revision of existing indexes, or the creation of new indexes.
This additional database evolution activity must be closely monitored and controlled. In many cases, these changes are the result of an oversight or a crisis, and each one tends to be reactionary in nature. The temptation is accept each of these changes at face value, and then implement the update with very little challenge or thinking. This is a mistake. Database changes can have an unpredictable ripple effect throughout the system, and index additions can reduce the efficiency of the database processing. Given this, the team is well advised to examine and question each new change with the same care and intensity as was exercised in the design phase.
