Table definitions and views are identified by schema and name if both DBMS have both schema and name, and only by name otherwise. If one side has no schemas and the other one has schemas, then it matches with the first found by name only. If the same object name is used for different schemas then these objects remain unmatched and counted as new. Name check is case-insensitive, so for example table myTable vs MyTable is considered as the same table.
All objects are built by reading object properties from different system metadata tables and views. Application reuses object reading logic from DBMS-specific products, so you can find more details about object definition reading in the 'How it works - Schema' section of documentation for corresponding tool:
Each supported DBMS uses its own set of data types. KS DB Merge Tools for Cross-DBMS calls these data types as native data types. To be able to compare some native data type with some other native data type from a different DBMS, KS DB Merge Tools for Cross-DBMS introduces the concept of generic data type: it is Number, String, Binary, Boolean, DateTime and Other. For example, a column of MySQL DECIMAL data type can be compared with a value of PostgreSQL smallint because both of these types are mapped to the Number generic data type. Other data type can not be compared with each other. See the Data types section to get more details about data type mapping.
Table definition is considered as changed if it has changed data columns (including order changes) or primary key columns. Data columns are identified by column name, generic type and nullability. The Pro version also allows to visually compare native but native type changes do not affect identification of the table definition changes. Primary key columns are identified by column names and order.
Indexes are identified by the combination of table name, indexed columns and name of the index. If no match is found, then the application tries to find a matching index by the table name and columns only (without index name). Index is counted as changed if it has changed Unique flag or index name. Index name is recognized as changed if index was matched by table name and columns, without an index name.
Foreign keys are identified by name of the child table and its columns used for the foreign key definition. Foreign key is counted as changed if it has changed parent table, its columns, or on update/delete actions.
Currently the view is identified as changed if it has changed CREATE VIEW definition text. Obviously, this makes almost any view counted as the same to be considered as changed because of DBMS-specific syntax changes. This is a subject of improvements, in the future views are going to be identified either by a set of columns and their types (like table definitions), or view definition text will have to go through some SQL normalization process to exclude DBMS-specific changes.
Last updated: 2023-12-14
