В программной инженерии , миграция схемы (также миграция базы данных , управление изменениями баз данных ) относится к управлению постепенными, обратимых изменений и управления версиями для реляционных схем баз данных . Миграция схемы выполняется в базе данных всякий раз, когда необходимо обновить или вернуть схему этой базы данных к более новой или более старой версии.
Миграции выполняются программно с помощью инструмента миграции схемы . При запуске с указанной желаемой версией схемы инструмент автоматизирует последовательное применение или отмену соответствующей последовательности изменений схемы до тех пор, пока она не будет приведена в желаемое состояние.
Большинство инструментов миграции схемы нацелены на минимизацию влияния изменений схемы на любые существующие данные в базе данных. Несмотря на это, сохранение данных в целом не гарантируется, поскольку изменения схемы, такие как удаление столбца базы данных, могут уничтожить данные (то есть все значения, хранящиеся в этом столбце, для всех строк в этой таблице удаляются). Вместо этого инструменты помогают сохранить значение данных или реорганизовать существующие данные в соответствии с новыми требованиями. Поскольку значение данных часто невозможно закодировать, настройка инструментов обычно требует ручного вмешательства.
Риски и преимущества
Миграция схемы позволяет исправлять ошибки и адаптировать данные по мере изменения требований. Они являются неотъемлемой частью эволюции программного обеспечения, особенно в гибких средах (см. Ниже).
Применение миграции схемы к производственной базе данных всегда сопряжено с риском. Базы данных для разработки и тестирования обычно меньше и чище. Данные в них лучше понимаются или, если все остальное не удается, объем данных достаточно мал, чтобы человек мог их обработать. Производственные базы данных обычно огромные, старые и полны сюрпризов. Сюрпризы могут быть получены из многих источников:
- Поврежденные данные, которые были записаны старыми версиями программного обеспечения и не были должным образом очищены
- Подразумеваемые зависимости в данных, о которых больше никто не знает
- Люди напрямую изменяют базу данных без использования назначенных инструментов
- Ошибки в инструментах миграции схемы
- Ошибки в предположениях о том, как следует переносить данные
По этим причинам процесс миграции требует высокого уровня дисциплины, тщательного тестирования и продуманной стратегии резервного копирования.
Миграция схемы в гибкой разработке программного обеспечения
При разработке программных приложений, поддерживаемых базой данных, разработчики обычно разрабатывают исходный код приложения в тандеме с развивающейся схемой базы данных. Код обычно имеет жесткие ожидания относительно того, какие столбцы, таблицы и ограничения присутствуют в схеме базы данных всякий раз, когда ему нужно взаимодействовать с одной, поэтому только версия схемы базы данных, для которой был разработан код, считается полностью совместимой с этой версией исходного кода. .
При тестировании программного обеспечения , хотя разработчики могут имитировать наличие совместимой системы баз данных для модульного тестирования , любой уровень тестирования выше, чем этот (например, интеграционное тестирование или тестирование системы ), разработчики обычно тестируют свое приложение в локальной или удаленной тестовой базе данных. схематически совместим с тестируемой версией исходного кода. В расширенных приложениях сама миграция может быть предметом тестирования миграции .
Благодаря технологии миграции схемы модели данных больше не нужно полностью разрабатывать заранее, и их легче адаптировать к изменяющимся требованиям проекта на протяжении всего жизненного цикла разработки программного обеспечения .
Отношение к системам контроля версий
Команды разработчиков программного обеспечения обычно используют системы контроля версий для управления и совместной работы над изменениями, внесенными в версии исходного кода. Разные разработчики могут разрабатывать разные, относительно старые или новые ветки одного и того же исходного кода, чтобы вносить изменения и дополнения во время разработки.
Предположим, что разрабатываемое программное обеспечение взаимодействует с базой данных, каждая версия исходного кода может быть связана по крайней мере с одной схемой базы данных, с которой она совместима.
При хорошей практике тестирования программного обеспечения миграции схемы могут выполняться в тестовых базах данных, чтобы убедиться, что их схема совместима с исходным кодом. Чтобы упростить этот процесс, инструмент миграции схемы обычно вызывается как часть автоматизированной сборки программного обеспечения как предварительное условие этапа автоматического тестирования .
Можно сказать, что инструменты миграции схемы решают проблемы управления версиями для схем баз данных так же, как системы управления версиями решают проблемы управления версиями для исходного кода. На практике многие инструменты миграции схемы фактически полагаются на текстовое представление изменений схемы (например, файлы, содержащие операторы SQL), так что история версий изменений схемы может эффективно храниться вместе с исходным кодом программы в VCS. Такой подход гарантирует, что информация, необходимая для восстановления совместимой схемы базы данных для конкретной ветви кода, может быть восстановлена из самого исходного дерева. Еще одно преимущество этого подхода - обработка одновременных конфликтующих изменений схемы; разработчики могут просто использовать свои обычные текстовые инструменты разрешения конфликтов, чтобы согласовать различия.
Отношение к эволюции схемы
Инструменты миграции схемы можно рассматривать как средство отслеживания истории развивающейся схемы.
Преимущества
Разработчикам больше не нужно удалять всю тестовую базу данных, чтобы создать новую тестовую базу данных с нуля (например, используя сценарии создания схемы из инструментов генерации DDL). Кроме того, если создание тестовых данных требует много времени, разработчики могут избежать повторного создания тестовых данных для небольших неразрушающих изменений схемы.