Обработка изменений схемы базы данных при загрузке новых версий

Во времена интенсивной разработки схема базы данных меняется как быстро, так и непрерывно, и к тому времени, когда наш еженедельный толчок к бета-сборке приходит в себя, схема изменилась настолько, что единственным разумным вариантом является обнуление всех таблиц, которые я могу, и скопируйте новые версии из моей базы данных разработчиков. Очевидно, что это не сработает после того, как мы запустим, так как ядерные производственные данные - это путь к катастрофе, поэтому мне было интересно, какие существуют стратегии для управления изменениями схемы базы данных из одной версии / ревизии в другую?

Некоторые я нашел или испытал:

1. Прямой нук-дамп из одной базы данных в другую (что я сейчас делаю)
2. Поддержание файла UPDATE.sql с инструкциями SQL, которые запускаются либо скриптом, либо вручную.
3. Сохранение файла update.php с соответствующим значением «db-schema-version» в активной базе данных

Третий вариант представляется наиболее разумным, но все еще существует вероятность того, что неправильно составленный SQL-запрос завершится неудачно в середине сценария, оставив базу данных в полуобновленном состоянии, что потребует восстановления резервной копии.

Это кажется не проблема, но это случается, так как мы как команда, мы используем phpMyAdmin, и я не могу даже полагаться на себя, помню, как скопировал выполненный оператор SQL для вставки в файл update.php. Как только вы перейдете на другую страницу, мне придется вручную переписать инструкцию SQL или отменить изменения и сделать это снова.

Полагаю, на что я надеюсь, так это на решение, которое не повлияет на наш установившийся рабочий процесс разработки?

Автоматизировать. Автоматизировать. Автоматизировать.

Вы на правильном пути с явным номером версии БД, но я бы пошел дальше и сделал бы, чтобы код явно знал, с какой именно схемой он будет работать (например, путем фиксации фактического сценария DDL и анализа его программой обновления). ); тогда во время обновления вам нужно только обнаружить существующую схему с помощью метаданных базы данных и INSERT / DROP / ALTER по мере необходимости, независимо от того, с какой версии до какой версии вы обновляете. (Вы также можете сохранить явный номер версии в самой базе данных и передать всю историю схемы с помощью программы установки, чтобы вам даже не требовалось обнаружение схемы.)

Потенциальные синтаксические ошибки в обновлении SQL-скрипта являются проблемой, но вы можете решить это, убедившись, что программа обновления может генерировать только правильные операторы DDL. (Формальные доказательства почти никогда не стоят в разработке корпоративного программного обеспечения - слишком много усилий для слишком малой уверенности - но я чувствую, что целостность базы данных является одним из немногих исключений: базовый SQL не является особенно сложным языком для формального ввода, и преимущество защита производственных данных настолько велика, что оправдано практически любое одноразовое предварительное усилие, особенно если оно должно работать для автоматической установки,)

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

Вот некоторые полезные вещи:

1. Всегда проверяйте свои изменения локально и проверяйте свой код с ним, просто ALTERпередачи недостаточно
2. Вам нужно синхронизировать, кто в первую очередь вносит свои изменения - простая вики-страница, где вы можете «взять номер», отлично сработала для моей команды.
3. Не пытайтесь исправить сломанное изменение, добавьте новое контр-изменение, чтобы отменить его, это безболезненно
4. Ваш код зависит от этих изменений - обязательно связывайте проблемы в вашей системе отслеживания ошибок с изменениями БД. Это очень полезно во время развертывания.
5. Включите изменения БД в свой CI - примените свои изменения к базе данных CI при фиксации. Кроме того, если у вас есть какие-либо тесты, которые используют базу данных, запустите их при фиксации.

Поскольку вы используете phpMyAdmin, то я предполагаю, что вы также используете MySQL.

Посмотрите на диаграммы EER Model в MySQL Workbench. Они очень помогли мне в поддержании и обновлении схем.

Во-первых, вы можете синхронизировать модель с источником базы данных. Так что изменения на диаграмме выдвигаются как команды ALTER TABLE. Это позволяет вам вносить изменения в схему на диаграмме, постоянно обновлять ее, а также при необходимости обновлять базу данных разработки.

Во-вторых, вы можете перепроектировать EER-диаграмму из источника базы данных. Что может быть удобно, принимая изменения в базе данных разработки и обновляя производственную базу данных, так как она будет вычислять различия.

В-третьих, он может быть использован для помощи в создании SQL, который должен войти в ваш файл "update.sql".

МИНУСЫ:

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

Это не инструмент переноса данных. Любые изменения, выходящие за рамки чисто схемы, по-прежнему требуют специального SQL.

Взгляните на http://south.aeracode.org - это библиотека миграции БД для Django (среда Python), но:

1. Вы можете получить отличные идеи из него (и, возможно, даже найти клон PHP)
2. вы можете использовать его независимо от остальной части Django для управления таблицами вашего приложения PHP / MySQL.

Он также может генерировать сценарии обновления схемы; он также обрабатывает изменения изменений в большинстве случаев автоматически.