Правильный инструмент для отслеживания изменений структуры DB
Прямо сейчас у меня есть проект PHP, и я отслеживаю все изменения в коде SVN. Я также хотел бы отследить изменения, внесенные в структуре базы данных.
Который является правильным инструментом для использования?
4 ответа
Существуют различные инструменты для отслеживания изменений структуры базы данных.
очень хорошим является mysql Workbench: http://www.mysql.com/products/workbench/
вы можете смоделировать свою базу данных с помощью этого инструмента, чтобы иметь возможность обновлять ее с синхронизацией.
Другой тип инструмента, который идеально подходит для svn: Миграция PHP
http://code.google.com/p/mysql-php-migrations/
С помощью этого инструмента вы создаете разные скрипты: 001_initial .php 002_changes.php например.
, и когда вы запустите инструмент, он применит файлы, которые не были применены для обновления вашей схемы.
Надеюсь, это вам поможет.
Обычно у меня есть php-скрипт, который я использую для создания структуры базы данных во время процесса установки и фазы тестирования.
Я считаю очень полезным иметь его прямо в репозитории svn, который отслеживает весь проект (у вас есть изменения, связанные с изменениями базы кода автоматически).
Для изменений в базе данных у нас есть (не работал, больше не работал) каталог в VCS:
+ dbchanges
|_ 01_database
|_ 02_table
|_ 03_data
|_ 04_constraints
|_ 05_functions
|_ 06_triggers
|_ 07_indexes
Когда вы вносите изменения в базу данных, вы помещаете изменение в файл .sql в правильный каталог с текущая дата и время в качестве имени файла. Если вы хотите обновить свою БД, вы запускаете сценарий интеграции, который просматривает эти каталоги по порядку и импортирует каждое изменение в базу данных.
Каталоги названы таким образом, чтобы убедиться, что порядок, в котором запускаются сценарии, правильный. (Таким образом, сценарий, который пытается вставить данные в таблицу, не будет запускаться до сценария, который создает указанную таблицу)
Файлы sql должны начинаться с комментария, который отображается пользователю, когда сценарий интеграции импортирует изменение, описывая, что оно делает. Он записывает имя каждого импортированного файла sql в файл, поэтому при следующем запуске скрипта он не применяет то же изменение снова.
Недостатком является то, что он не поддерживает откаты, потому что вам придется сохранять обратные операции, а для некоторых операций это невозможно, например, DELETE. Другой недостаток заключается в том, что если вы каким-то образом потеряете файл, который отслеживает уже примененные изменения, вам придется воссоздавать свою БД с нуля.
Я обычно решаю эту проблему с помощью скриптовых дампов базы данных, содержащих определения таблиц и все остальное, что вас может заинтересовать. Это даже позволяет обрабатывать данные самостоятельно, если ваша БД не слишком велика.
Для более систематического подхода вы можете взглянуть на Liquibase. Я сам не пробовал, поэтому не могу комментировать практическое использование, но кажется, что это может быть очень ценным инструментом для версионирования БД.