|
|
|
|
|
When comparing a related object (such as an index), Compare Objects will get the list of all indexes for the two tables. It will then go through these lists of indexes to determine which indexes "match" (eg. are the "same" index in both tables) and which indexes do not "match" (eg. are defined in one table but not the other).
The key to this matching process is the compare parameters. These are the parameters which are used to determine whether two objects are "the same". For instance, when we compare the indexes from two tables, we do not compare on index name, instead we comnpare on the index-columns - if these are the same then the two indexes are "the same".
The following table shows how some common objects are compared:
Object |
Compare Parameters |
Parameters Compared |
Parameters Not Compared |
Index |
index columns |
type (unique/non-unique) |
table name, index name |
Foreign Key |
referenced table, fk columns, referenced columns |
update rule, delete rule |
constraint name |
Primary Key |
pk columns |
|
|
Check Constraint |
constraint text |
|
constraint name |
When you are comparing tables in two different schemas, AQT will also look at the schema of the referenced tables.
For instance suppose one table has the following foreign key:
alter table TEST.DEPARTMENT
foreign key (ADMRDEPT)
references TEST.DEPT_INFO (DEPTNO)
This will be considered the same as the foreign key on PROD.DEPARTMENT if it has the following definition:
alter table PROD.DEPARTMENT
foreign key (ADMRDEPT)
references PROD.DEPT_INFO (DEPTNO)
It will not compare successfully if this definition had:
references TEST.DEPT_INFO (DEPTNO)
In other words, if the schema of the Referenced table (DEPT_INFO) is the same as the table schema, AQT will assume that the same applies for the compared-to table.
Similar logic is used for Aliases and Synonyms - if the referenced object has the same name as the table schema, AQT will assume the same applies for the compare-to table.
