Введение
Одним из этапов разработки корпоративных информационных систем является разработка структуры базы данных. При проектировании, внедрении и эксплуатации возникают случаи, при которых требуется вносить изменения в структуру баз данных. Это ошибки при проектировании и создании БД, добавление новых функциональных возможностей в информационную систему, ее интеграция с другими информационными системами и пр.
При этом, ситуация усугубляется тем, что по мере эксплуатации и развития информационной системы требуется работа с несколькими типами БД:
‒ рабочая БД — база данных, которая находится в стадии эксплуатации конечными пользователями. Может быть несколько рабочих БД для разных заказчиков (объектов внедрения) и с отличающейся структурой данных;
‒ тестовая БД — база данных, предназначенная для тестирования изменений. Может быть несколько (например, по одной на каждую рабочую). После тестирования изменения переносятся из тестовой БД в рабочую;
‒ БД«песочница» — база данных, предназначенная отладки и тестирования отдельным разработчиком. После тестирования изменения переносятся из БД «песочница» в тестовую.
При внесении изменений часто можно наблюдать следующие проблемы:
‒ несогласованное внесение изменений в БД несколькими разработчиками;
‒ необходимость внесения различных изменений в несколько разных БД;
‒ необходимость внесения изменений в БД без потери имеющихся в ней данных.
Таким образом, основными задачами при внесении изменений являются следующие:
‒ совершение изменений структуры баз данных, самих данных, настроек баз данных и сервера, хранимых процедур, представлений и пр.;
‒ перенос части изменений из БД «песочниц» в тестовую БД, а затем в рабочую БД;
‒ выполнение изменений без повторов;
‒ своевременное внесение только необходимых изменений для каждой рабочей БД.
Подходы квнесению изменений вБД
Есть несколько подходов:
1) Сравнение схем тестовой и рабочих БД.
2) Сравнение заскриптованной схемы (и данных) с рабочей БД.
3) На основе последовательных (инкрементных) SQL-скриптов.
4) Метод идемпотентных изменений.
Сравнение схем тестовой и рабочих БД.
Основной принцип данного подхода заключается в переносе всех изменений в структуре данных из тестовой в рабочую БД. Для этого генерируется скрипт, отражающий в себе все различия между тестовой и рабочей БД (diff-скрипт). Затем этот скрипт выполняется в рабочей БД, приводя ее в состояние, идентичное тестовой.
Плюсы:
‒ изменения в тестовой БД можно выполнять визуальными средствами;
‒ скрипт содержит только SQL-операторы изменения структуры данных.
Минусы:
‒ наличие нескольких тестовых БД (как правило, по одной на каждую из рабочих) вынуждает проводить процедуру несколько раз;
‒ внесение ненужных изменений для рабочей БД из тестовой;
‒ автоматическая генерация diff-скриптов не всегда корректно справляется со своей задачей. При перепроверке автоматически сгенерированных скриптов исчезает суть подхода, т. к. проще писать скрипты сразу вручную;
‒ невозможность обновить настройки рабочих БД и серверов;
‒ отсутствие хороших бесплатных инструментов. Среди платных инструментов требуется лицензия на каждый хост.
Сравнение заскриптованной схемы (и данных) с рабочей БД.
Основой данного подхода является каталог со скриптами, который позволяет создать базу данных с нуля (схемы, справочники и пр.). Разработчик должен вручную вносить изменения в скрипты, которые находятся в этом каталоге. После этого запускается инструмент, который сравнивает каталог с рабочей БД. Затем генерируется diff-скрипт и выполняется в рабочей БД.
Плюсы:
‒ необязательное скриптование всех изменений. Некоторые изменения являются вспомогательными и, как правило, используются разработчиками для тестирования новых функциональных возможностей;
‒ возможность изменения не только структуры, но и данных.
Минусы:
‒ ошибки, возникающие при ручном создании (изменении) скриптов;
‒ нет возможности сделать различные изменения в различных рабочих БД с помощью единого каталога. Для каждой рабочей БД необходимо создавать свой собственный каталог скриптов;
‒ автоматическая генерация diff-скрипта не всегда корректно справляется со своей задачей;
‒ нет возможности сравнивать настройки баз данных и сервера;
‒ отсутствие готовых решений.
На основе последовательных (инкрементных) SQL-скриптов.
Основой данного подхода является ручное написание скриптов (изменение структуры и данных в базе данных, настроек баз данных и пр.). Каждому из этих скриптов присваивается имя, удобное для разработчика, затем помещается в каталог. В определенное время запускается инструмент, выполняющий данные скрипты по порядку. Имя последнего можно запомнить во вспомогательной таблице рабочей БД для того, чтобы предотвратить повторное применение.
Плюсы и минусы данного подхода, в основном, совпадают с предыдущим подходом, но имеются и отличия.
Плюсы:
‒ хранение в скриптах изменения настроек баз данных, сервера и пр.;
‒ хранение всех скриптов для различных рабочих БД в едином каталоге.
Минусы:
‒ отсутствие пояснения к скриптам не позволяет сходу определить, за какие изменения они отвечают;
‒ готовые решения имеют высокую цену.
Метод идемпотентных изменений.
В основе данного подхода лежит один скрипт, позволяющий создать новую базу данных с нуля до последней версии. Каждое из изменений добавляется в конец скрипта разработчиком. Данный скрипт содержит ключевые слова if not exist, которые позволяют предотвратить повторное применение некоторых изменений.
Плюс:
‒ получение последней версии базы данных одним скриптом.
Минусы:
‒ потеря данных (например, если в скрипте изменений требуется удалить таблицу, а после создать новую с тем же именем, то после ее создания все данные в таблице будут потеряны);
‒ сложность написания и поддержки данного скрипта.
Готовые решения
Flywaydb — программный продукт, использующий 3-й подход. Имеет поддержку огромного количества баз данных. При его использовании необходимо строгое именование скриптов.
Wizardby — программный продукт, позволяющий обновлять только структуру базы данных. Не способен изменять хранимые процедуры, представления, настройки базы данных и сервера. Имеет свой собственный язык написания миграций.
ECM7 Migrator — продукт, позволяющий все изменения базы данных записывать в виде классов, написанных на языке программирования. Для каждой миграции указывается номер версии, в которую перейдет база данных после внесения описанных в миграции изменений. Учет версий ведется автоматически: информация о выполненных миграциях сохраняется в базе данных в специальной таблице. Каждый класс-миграция наследуется от базового класса Migration и реализует его методы Apply (применить изменения) и Revert (откатить изменения). Внутри этих методов разработчик при помощи специального фреймворка описывает действия, которые необходимо выполнить над базой данных. При создании миграции указывается строка подключения к серверу.
Выводы
Сравнив данные подходы, можно сделать вывод, что больше всего плюсов имеет подход на основе инкрементных изменений. Используя репозиторий можно решить несколько минусов данного подхода. Например, при переименовании скрипта с существующим именем разработчик будет об этом уведомлен. С помощью ветвлений можно решить задачу по обновлению разных рабочих БД, используя различные наборы скриптов для каждого ветвления. Каждый comit может содержать описание изменений в добавленных скриптах. Пропадает строгая структура хранения каталога со скриптами. Разработчик делает удобную структуру для себя. Хранение скриптов возможно в удаленном репозитории.
Литература:
- Скотт Амблер, Прамодкумар Дж. Садаладж Рефакторинг баз данных: эволюционное проектирование. М.: Вильямс, 2016.
- Кузнецов С. М. Информационные технологии: учебное пособие. — Новосибирск: НГТУ, 2011.
- Поль М. Дюваль, Стивен М. Матиас III, Эндрю Гловер Непрерывная интеграция: улучшение качества программного обеспечения и снижение риска. М.: Вильямс, 2016.
- Вольф Э. Continuous delivery. Практика непрерывных апдейтов. Спб: Питер, 2018.
