Анализ подходов миграций баз данных в корпоративных информационных системах | Статья в журнале «Молодой ученый»

Отправьте статью сегодня! Журнал выйдет 16 ноября, печатный экземпляр отправим 20 ноября.

Опубликовать статью в журнале

Автор:

Рубрика: Информационные технологии

Опубликовано в Молодой учёный №22 (208) июнь 2018 г.

Дата публикации: 02.06.2018

Статья просмотрена: 216 раз

Библиографическое описание:

Удинцев, П. В. Анализ подходов миграций баз данных в корпоративных информационных системах / П. В. Удинцев. — Текст : непосредственный // Молодой ученый. — 2018. — № 22 (208). — С. 62-64. — URL: https://moluch.ru/archive/208/50955/ (дата обращения: 04.11.2024).



Введение

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

При этом, ситуация усугубляется тем, что по мере эксплуатации и развития информационной системы требуется работа с несколькими типами БД:

рабочая БД — база данных, которая находится в стадии эксплуатации конечными пользователями. Может быть несколько рабочих БД для разных заказчиков (объектов внедрения) и с отличающейся структурой данных;

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

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

При внесении изменений часто можно наблюдать следующие проблемы:

‒ несогласованное внесение изменений в БД несколькими разработчиками;

‒ необходимость внесения различных изменений в несколько разных БД;

‒ необходимость внесения изменений в БД без потери имеющихся в ней данных.

Таким образом, основными задачами при внесении изменений являются следующие:

‒ совершение изменений структуры баз данных, самих данных, настроек баз данных и сервера, хранимых процедур, представлений и пр.;

‒ перенос части изменений из БД «песочниц» в тестовую БД, а затем в рабочую БД;

‒ выполнение изменений без повторов;

‒ своевременное внесение только необходимых изменений для каждой рабочей БД.

Подходы квнесению изменений вБД

Есть несколько подходов:

1) Сравнение схем тестовой и рабочих БД.

2) Сравнение заскриптованной схемы (и данных) с рабочей БД.

3) На основе последовательных (инкрементных) SQL-скриптов.

4) Метод идемпотентных изменений.

Сравнение схем тестовой и рабочих БД.

Основной принцип данного подхода заключается в переносе всех изменений в структуре данных из тестовой в рабочую БД. Для этого генерируется скрипт, отражающий в себе все различия между тестовой и рабочей БД (diff-скрипт). Затем этот скрипт выполняется в рабочей БД, приводя ее в состояние, идентичное тестовой.

Плюсы:

‒ изменения в тестовой БД можно выполнять визуальными средствами;

‒ скрипт содержит только SQL-операторы изменения структуры данных.

Минусы:

‒ наличие нескольких тестовых БД (как правило, по одной на каждую из рабочих) вынуждает проводить процедуру несколько раз;

‒ внесение ненужных изменений для рабочей БД из тестовой;

‒ автоматическая генерация diff-скриптов не всегда корректно справляется со своей задачей. При перепроверке автоматически сгенерированных скриптов исчезает суть подхода, т. к. проще писать скрипты сразу вручную;

‒ невозможность обновить настройки рабочих БД и серверов;

‒ отсутствие хороших бесплатных инструментов. Среди платных инструментов требуется лицензия на каждый хост.

Сравнение заскриптованной схемы (и данных) с рабочей БД.

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

Плюсы:

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

‒ возможность изменения не только структуры, но и данных.

Минусы:

‒ ошибки, возникающие при ручном создании (изменении) скриптов;

‒ нет возможности сделать различные изменения в различных рабочих БД с помощью единого каталога. Для каждой рабочей БД необходимо создавать свой собственный каталог скриптов;

‒ автоматическая генерация diff-скрипта не всегда корректно справляется со своей задачей;

‒ нет возможности сравнивать настройки баз данных и сервера;

‒ отсутствие готовых решений.

На основе последовательных (инкрементных) SQL-скриптов.

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

Плюсы и минусы данного подхода, в основном, совпадают с предыдущим подходом, но имеются и отличия.

Плюсы:

‒ хранение в скриптах изменения настроек баз данных, сервера и пр.;

‒ хранение всех скриптов для различных рабочих БД в едином каталоге.

Минусы:

‒ отсутствие пояснения к скриптам не позволяет сходу определить, за какие изменения они отвечают;

‒ готовые решения имеют высокую цену.

Метод идемпотентных изменений.

В основе данного подхода лежит один скрипт, позволяющий создать новую базу данных с нуля до последней версии. Каждое из изменений добавляется в конец скрипта разработчиком. Данный скрипт содержит ключевые слова if not exist, которые позволяют предотвратить повторное применение некоторых изменений.

Плюс:

‒ получение последней версии базы данных одним скриптом.

Минусы:

‒ потеря данных (например, если в скрипте изменений требуется удалить таблицу, а после создать новую с тем же именем, то после ее создания все данные в таблице будут потеряны);

‒ сложность написания и поддержки данного скрипта.

Готовые решения

Flywaydb — программный продукт, использующий 3-й подход. Имеет поддержку огромного количества баз данных. При его использовании необходимо строгое именование скриптов.

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

ECM7 Migrator — продукт, позволяющий все изменения базы данных записывать в виде классов, написанных на языке программирования. Для каждой миграции указывается номер версии, в которую перейдет база данных после внесения описанных в миграции изменений. Учет версий ведется автоматически: информация о выполненных миграциях сохраняется в базе данных в специальной таблице. Каждый класс-миграция наследуется от базового класса Migration и реализует его методы Apply (применить изменения) и Revert (откатить изменения). Внутри этих методов разработчик при помощи специального фреймворка описывает действия, которые необходимо выполнить над базой данных. При создании миграции указывается строка подключения к серверу.

Выводы

Сравнив данные подходы, можно сделать вывод, что больше всего плюсов имеет подход на основе инкрементных изменений. Используя репозиторий можно решить несколько минусов данного подхода. Например, при переименовании скрипта с существующим именем разработчик будет об этом уведомлен. С помощью ветвлений можно решить задачу по обновлению разных рабочих БД, используя различные наборы скриптов для каждого ветвления. Каждый comit может содержать описание изменений в добавленных скриптах. Пропадает строгая структура хранения каталога со скриптами. Разработчик делает удобную структуру для себя. Хранение скриптов возможно в удаленном репозитории.

Литература:

  1. Скотт Амблер, Прамодкумар Дж. Садаладж Рефакторинг баз данных: эволюционное проектирование. М.: Вильямс, 2016.
  2. Кузнецов С. М. Информационные технологии: учебное пособие. — Новосибирск: НГТУ, 2011.
  3. Поль М. Дюваль, Стивен М. Матиас III, Эндрю Гловер Непрерывная интеграция: улучшение качества программного обеспечения и снижение риска. М.: Вильямс, 2016.
  4. Вольф Э. Continuous delivery. Практика непрерывных апдейтов. Спб: Питер, 2018.
Основные термины (генерируются автоматически): рабочая БД, изменение, скрипт, баз данных, база данных, подход, тестовая БД, данные, настройка баз данных, разработчик.


Задать вопрос