Original Publication Date: 2004-Sep-01
Included in the Prior Art Database: 2004-Sep-01
The proposed Change Processor extracts customizations applied to database objects, builds related alter statements in order to reapply them if lost because of maintenance application. It can be also useful to replicate the same set of customization on different systems.
Many customers, running applications based on database usage (like DB2), often experience the difficulty to preserve customisations when periodic maintenance for database definitions is supplied by application providers. It is, in fact a general need of any customer to adapt the database definitions to a particular environment according to its characteristics. It is very important to define the best solution for database objects in order to achieve the best performances. The solution is generally different from environment to environment, depending on the amount of data that must be maintained in the database, and, in general on any systems' characteristics. This means that each database object has to be changed in order to fit customer environment and needs. This generally causes difficulties if it is necessary to apply any maintenance to the customized objects; customisations, in fact, are lost and they have to be coded again on the new objects.
Another problem that is often asked to be addressed is a way to extract customisation from database objects and to be able to apply them automatically to other similar objects that reside in different systems. In other words, it is often necessary to have an easy way to clone similar database environment changes. Change processor
The idea to solve previous problems is to create a processor that extracts changes applied to objects created through DDL statements for SQL-like languages (and in general objects defined through languages that have an ALTER statement able to change objects). After the extraction, the processor creates automatically ALTER statements that reflect the changes and that can be automatically applied to the database objects.
This processor would be useful in the following different scenarios:
1. An environment with applications based on a DB2 database, working on all the database related objects like table spaces, tables and other objects. If customisations have been done on some object definitions in order to make them more suitable for a certain environment, when further official maintenance are applied to the database definitions, all or part of these customisations are lost. If the customisations have been extracted through the processor and the related ALTER statements have been produced, the changes can be re-applied easily to the objects...