Copyright: © 1998-2000 by Boris Loboda ("Soft Audit" software company).


Общие Сведения

InterBase DataBase Comparer v.3.xx.

InterBase DataBase Comparer (IB Comparer) предназначен для нахождения различий в двух базах данных формата InterBase (*.GDB-файлы) по их скриптам (DDL-файлам), содержащим метаданные. Результатом сравнения является выходной скрипт, в котором содержатся команды модификации целевой БД (Target) для приведения ее в соответствие к эталонной БД (Master).

Cравнение производится по следующим объектам БД:

- Домены (DOMAIN)

- UDF's (User Defined Function)

- Таблицы (TABLE) /включая поля, первичные ключи, CONSTRAINT's/

- VIEW's

- Индексы (INDEX)

- Вторичные ключи (FOREIGN KEY, CONSTRAINT, CHECK)

- Генераторы (GENERATOR)

- Исключения (EXCEPTION)

- Процедуры (PROCEDURE)

- Триггеры (TRIGGER)

- Роли (ROLE & GRANT)

Для сравнения Вы должны по каждой из БД получить скрипты (DDL-файлы) с их метаданными (в InterBase Windows ISQL -> MetaData -> Extract Database...), и указать входные параметры для сравнения. Последние версии IB Comparer поддерживают также обработку скриптов InterBase v.6.x (полученных в IBConsole).

Начиная с версии 3.00.beta5 IB Comparer может работать совместно с IBExpert (c) by HK-Software (http://www.ibexpert.com). Во-первых, как в плане восприятия его скриптов, которые в деталях несколько отличаются от стандартных, формируемых в Windows iSQL или IBConsole. Во-вторых - IB Comparer может работать и как PlugIn в IBExpert.

(c) 1998-2000, by Boris Loboda, barry@audit.kharkov.com

http://www.audit.kharkov.com/barry/


Входные Данные

Входными данными для сравнения структур двух БД являются скрипты, описывающие структуру сравниваемых Баз Данных (DDL-файлы). Их можно сформировать в InterBase Windows ISQL -> Metadata -> Extract Database.

При этом одна из БД считается целевой (модифицируемой) /Target/ - ее DDL-файл указывается в поле "Target DDL-file...". Вторая БД считается образцовой /Master/ и ее DDL-файл указывается в поле "Master DDL-file...". Вам необходимо также указать имя файла для выходного скрипта, в который будут записаны команды по модификации целевой БД для приведения ее в соответствие к образцовой - поле "Result SQL-file...".

Этого достаточно - для проведения сравнения нажмите на кнопку [Compare]. По завершению сравнения скрипт для модификации будет записан в указанный файл, и Если Вы не отключили опцию "Show Script", то на страничке "Update Script" Вам будет показан сформированный SQL-файл.

Вы также можете выбрать объекты БД, по которым проводить сравнение (домены, таблицы, индексы, вторичные ключи, генераторы, исключения, процедуры, триггеры, UDF's, VIEW's, ROLE's).

На страничке "Warnings" после проведения сравнения могут быть указаны различного рода предупреждения, природа которых имеет сомнительный характер в отношении модификации данных. Например, поля разного типа в одних и тех же таблицах одного и то же наименования, или различие в длинах одних и тех же строковых полей, разлючающиеся позиции полей в таблицах и т.п.


Сравнение Доменов

Команды по созданию новых доменов добавляются в выходной скрипт в самом начале, перед обновлением таблиц.

Команды на удаление отсутствующих в образцовой БД доменов формируются в самом конце скрипта, после обновлений всех остальных объектов БД.

Никаких действий по модификации различающихся в двух БД доменов с одинаковыми наименованиями не делается.


Сравнение UDF

По результатам сравнения в выходной скрипт добавляются определения новых UDF (через DECLARE EXTERNAL FUNCTION...) и удаляются несуществующие (через DROP EXTERNAL FUNCTION...). Если UDF присутствует в обоих БД, но ее определения различаются, она обновляется через последовательность DROP... DECLARE...


Сравнение Таблиц и Полей

При сравнении таблиц в первую очередь проверяется наличие всех таблиц образцовой БД в целевой БД. Для отсутствующих таблиц в выходной скрипт помещаются команды на их создание.

Далее в целевую БД добавляются недостающие поля по соответствующим таблицам.

После этого проводится сравнение совпадающих полей и первичных ключей в обоих БД. Не всегда найденные при этом различия можно ликвидировать традиционными методами и в некоторых случаях необдуманное выполнение таких команд может привести к проблемам в целевой БД, поэтому Вы должны проявлять особое внимание на сформированные ниже команды. Далее сравнение идет в следующей последовательности:

- Проверяется соответствие типов полей - если есть различия, то на страничку "Warnings" пишется предупреждение, так как однозначно эту проблему решить тяжело. Команды на преобразование формируются только если выявлено несовпадение для типов FLOAT <-> DOUBLE PRECISION.

- Проверяется соотвествие длин строковых полей. При различиях формируется предупреждение и в скрипт включается команда по обновлению соотвествующих данных в системных таблицах. Тут также нет однозначного решения, так как в случае если в целевой БД поле длиннее чем в образцовой, и заполнено данными, то это может привести к проблемам.

- Проверяется соответствие полей на признак Nullable/NOT NULL, при различиях формируется команда на обновление системных таблиц. Проблема, которая при этом может проявиться - поля для которых будет устанавливаться признак "NOT NULL" могут быть заполнены нулевыми значениями, поэтому сразу после модификации такого поля желательно в него занести значения, иначе последующий Backup/Restore для БД закончится плачевно (БД не будет восстановлена).

- Проверяется соотвествие полей по позициям в таблицах (порядок следования полей). Формируется команда на обновление системных таблиц (корректируются позиции полей).

- При наличии в образцовой таблице первичного ключа, проверяется есть ли он у целевой. Если нет - то формируется команда на создание первичного ключа. Проблема, я думаю, очевидна - в целевой таблице могут оказаться совпадающие по первичному ключу значения, поэтому данная команда также идет в комментариях. Если первичный ключ есть в целевой БД и отсутствует в образцовой, то фомируется команда на его уничтожение в системных таблицах. Для первичного ключа также проверяется идентичность определения первичного ключа. Если ключи различаются, то производится "замена" первичного ключа. Вначале в целевой БД удаляются вторичные ключи (если есть) на старый первичный ключ, затем сам первичный ключ. После этого создается новый первичный ключ на данную таблицу и восстанавливаются вторичные ключи на вновь созданный первичный ключ по определениям из образцовой БД.

Ну и в заключение - проверяется наличие в целевой БД "лишних" полей и таблиц (отсутствующих в образцовой). Если таковые находятся, то формируются команды по их уничтожение. Но эти команды помещаются в самом хвосте скрипта (после модификации процедур и триггеров), так в целевой БД в старых процедурах и триггерах могут быть ссылки на старые таблицы (поля).


Сравнение VIEW

View's сравниваются чисто по тексту их определенй без синтаксического разбора. Добавление новых View's осуществляется после обновления процедур. Затем следует удаление несуществующих и обновление одноименных View с различающимся определением (через DROP/CREATE).


Сравнение Индексов

Добавление новых индексов проводится после обновления таблиц. Затем при необходимости выполняется модификация различающихся индексов с совпадающими наименованиями (через DROP - CREATE).

Уничтожение отсутсвующих индексов делается в конце скрипта, перед удалением отсутсвующих таблиц.

По индексам выполняется полное (исчерпывающее) сравнение и, соответственно, обновление.


Сравнение Вторичных Ключей

Проверка и добавление вторичных ключей делается после согласования таблиц, в связи с тем, что в целевой (старой) БД может и не оказаться либо таблиц, либо полей по которым формируются вторичные ключи.

Уничтожение отсутствующих вторичных ключей выполняется через модификацию системных таблиц.

Процесс сравнения вторичных ключей включает в себя также сравнение CONSTRAINT's и определений CHECK.


Сравнение Генераторов

Добавление отсутствующих генераторов проводится перед обновлением процедур и триггеров, так как в новых процедурах и триггерах вполне могут оказаться ссылки на новые генераторы.

Удаление несуществующих генераторов следует после обновления процедур и тригерров (в конце скрипта). Так как в ISQL отсутствует команда "DROP GENERATOR...", то удаление генераторов производится непосредственно в системной таблице RDB$GENERATORS. Вроде бы никакими побочными эффектами это не грозит, но для страховки рекомендуется все же сделать контрольный Backup/Restore для модифицируемой БД, предварительно сохранив оригинал.


Сравнение Исключений

Добавление новых и модификация существующих исключений проводится перед обновлением процедур и триггеров.

Удаление отсутствующих исключений выполняется после обновления процедур и тригерров.


Сравнение Процедур

Сравнение и модификация процедур следует после создания новых доменов, модификации таблиц и создания новых генераторов и исключений, так как в новых процедурах могут быть ссылки на новые домены, таблицы, новые их поля и на вновь созданные генераторы и исключения. Обновление процедур следует перед обновлением триггеров, так триггеры могут ссылаться на процедуры, а процедуры на триггеры - нет.

На первом этапе в скрипт включаются отсутствующие в целевой БД процедуры с пустым "содержимым":

CREATE PROCEDURE <Proc_Name> <список параметров> AS BEGIN EXIT; END ^

После создания всех новых процедур формируются команды на их модификацию с реальным содержимым.

Затем проводится сравнение присутствующих в обоих БД процедур и формирование команд на модификацию различающихся. Сравнение процедур выполняется весьма "тупо" - сравнением их текста с игнорированием пустых строк. Хотя такой метод может приводить и к излишним модификациям синтаксически совпадающих процедур, но такой подход упрощает задачу анализа и в данном случае оправдан.

В завершение, проверяются отсутствующие в образцовой БД процедуры - команды по их уничтожению помещаются в скрипт после команд модификации тригерров, перед удалением отсутствующих доменов. Удаление процедур для надежности разбито на две фазы. Вначале производится ALTER удаляемых процедур - со списком параметров, но с пустым содержимым, таким образом мы избавляемся от взаимных ссылок удаляемых продедур друг на друга и другие объекты БД. На второй фазе облегченные, никуда не ссылающиеся процедуры удаляются через DROP PROCEDURE.


Сравнение Триггеров

Сравнение и модификация триггеров выполняется после добавления новых доменов, обновления таблиц, генераторов, исключений и процедур, так как на все эти объекты можно ссылаться из триггера.

На первом этапе в скрипт включаются команды на создание новых триггеров, отсутствующих в модифицируемой БД.

Затем сверяются тексты присутствующих в обоих БД тригеррах и фомируются команды по их обновлению. Тригерры обновляются через DROP.../CREATE..., так как InterBase 5.x-версий почему-то не воспнимает ссылки на OLD.<field> в триггерах BEFORE DELETE и AFTER DELETE, если триггеры обновлять через ALTER TRIGGER.

После этого сразу же формируются команды по уничтожению отсутствующих в образцовой БД тригерров.


Сравнение Ролей

Сравнение ролей (ROLE's) включает собственно сравнение ролей и определений GRANT. Новые роли добавляются после добавления/модификации таблиц, процедур, триггеров.

Несуществующие роли удаляются через DROP ROLE rolename.

В новую БД добавляются также новые определения GRANT. Несуществующие просто пишутся в список предупреждений и добавляются комментариями в выходной скрипт.