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

Я думаю, что не сильно ошибусь, если скажу что большинство проектов, в которых принципы экстремального программирования работают наилучшим образом, предполагают работу с базой данных. Ведь разработка систем автоматизации бизнеса как правило связано с накоплением и анализом данных. Но если для внесения изменения в код приложения большинство современных сред разработки содержат средства автоматического рефакторинга, то для аналогичных изменений структуры базы данных нет ничего! А ведь для сохранения эффективности системы в целом изменениям должен подвергаться не только код приложения, но и структура данных. Кроме того, проведение рефакторинга структуры данных вручную осложняется тем, что в базе данных код процедур сильно связан со структурой других объектов и даже самое простое изменение требует длительных рутинных действий.
Разработчики систем под управлением Interbase или Firebird счастливые люди – теперь они получают в свое распоряжение систему, в которой реализованы функции автоматического рефакторинга.

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

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

• в базе данных делаем копию объекта с другим именем
• для таблиц - переливаем данные из старой таблицы в новую
• для таблиц - восстанавливаем все констрейнты и триггера
• раздаем пользователям права на новый объект
• старый объект убиваем

Просто, но аккуратной работы минут на 5-10.

А теперь представьте себе, что вам нужно переименовать таблицу, которая используется в процедурах, представлениях и констрейнтах другой таблицы. Необходимо поменять не только имя самой таблицы, но и все объекты, использующие ее. Дело осложняется вот еще чем: как известно, сервера Interbase/Firebird жестко контролируют непротиворечивость метаданных базы – в базе не может быть процедур, ссылающихся на несуществующие таблицы и поля, процедуры, представления. Если на таблицу есть ссылка по внешнему ключу, то ее так же нельзя удалить и т.п.

Это значит, что нам необходимо:

• найти все зависимые объекты
• поменять зависимые объекты так, чтобы они не использовали старую таблицу
• переименовать таблицу по первому алгоритму
• поменять зависимые объекты так, чтобы они использовали новую таблицу

Временно «отсоединить» процедуру, триггер и таблицу от старой таблицы относительно легко: тело процедур и триггеров можно сделать пустым, а у таблицы удалить констрейнт. Все намного хуже с представлениями. Представления нельзя поменять (ALTER), его можно только удалить и создать заново. А это означает, что надо позаботиться обо всех зависимых процедурах, триггерах и других представлениях рекурсивно!

Попробуйте удалить таблицу, которая используется в 3-х процедурах – сервер БД выдаст сообщение “Cannot delete. COLUMN NNN. There are 3 dependencies.” Сервер не говорит, в каких именно процедурах пользуется таблица, что тоже осложняет задачу поиска зависимостей. Соответственно есть два варианта:

• сделать полный скрипт БД и вручную поискать зависимые объекты в файле.
• использовать таблицу RDB$DEPENDENCIES для поиска зависимых объектов. Современные средства разработки умеют в более-менее приемлемом виде показывать список зависимых объектов на базе RDB$DEPENDENCIES, но что бы точно узнать как используется таблица или колонка надо открывать этот объект и искать по тексту.

Оба эти способа легкими не назовешь. Таким образом, чтобы переименовать один объект необходимо проделать действия со многими объектами.

На переименовку таблицы CUSTOMER, на которую ссылается 2 процедуры, триггер и одна таблица, в демонстрационной базе EMPLOYEE ушло 10 минут кропотливого, неинтеллектуального, с точки зрения разработчика, труда. В средней базе с 50-70 таблицами, двумя сотнями процедур и триггеров, тремя десятками представлений, это займет минут 20-30 на один объект. В большой базе с большим количеством объектов и большим объемом хранимых процедур эта цифра будет еще больше.

Думаю уже понятно, почему в более или менее работающей системе структура базы данных практически не меняется – это крайне трудоемкое занятие. Как результат – разница в идеологии, на которой построена база данных и идеологией приложения стремительно нарастает, что приводит к «заплаточной» технологии программирования. Очевидно, что надежности и скорости это не добавляет.

Теперь посмотрим, насколько задача упрощается с помощью специального ПО для разработчика – а именно с помощью Interbase/Firebird Development Studio. Напомню, что требовалось переименовать таблицу, название которой выбрано неудачно и не отражает сущности хранимых данных. Среди поддерживаемых в IB/FB Development Studio операций рефакторинга имеется операция Rename References. Она переименовывает ссылки на указанный объект (при этом второй объект, на который будут ссылаться объекты, должен быть создан в базе данных до начала этой операции). Для проведения переименования потребуется сделать три-четыре простых операции:

1. Создать копию объекта с новым именем.
2. Для таблицы выполнить запрос на перенос данных из старой таблицы в новуюt: INSERT INTO newname SELECT … FROM oldname ).
3. Выполнить команду переименовки ссылок (в редакторе базы данных эта команда создает SQL скрипт, который выполняется по команде пользователя).
4. Убедиться, что ссылок на старый объект не осталось и удалить его.

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