Контроль версий базы данных для MySQL

Какой метод вы используете для управления версиями своей базы данных? Я передал все наши таблицы базы данных в виде отдельных сценариев .sql в наш репозиторий (mercurial). Таким образом, если какой-либо член команды внесет изменения в таблицу сотрудников, скажем, я сразу же узнаю, какая конкретная таблица была изменена, когда я обновил свой репозиторий.

Такой метод был описан в: Каковы наилучшие методы для сценариев базы данных при управлении кодом . В настоящее время я пишу скрипт python для выполнения всех файлов .sql в папке базы данных, однако проблема зависимостей из-за ограничений внешнего ключа гарантирует, что мы не можем просто запускать .sql-файлы в любом порядке.

Сценарий python должен сгенерировать файл с порядком выполнения .sql-файлов. Он будет выполнять файлы .sql в том порядке, в котором они появляются в файле tableorder.txt. Таблица не может быть выполнена до тех пор, пока не будет выполнена ее таблица внешнего ключа, например:

tableorder.txt

table3.sql
table1.sql
table7.sql и т. д.

Уже я создал список зависимостей для каждой таблицы, начиная с кода, анализируя результат команды «show create table» mysql. Список зависимостей может выглядеть так:

tblstate: tblcountry //tblcountry.sql must be executed before tblstate.sql etc tblemployee: tbldepartment, tblcountry 

Чтобы сгенерировать содержимое tableorder.txt, мне понадобится алгоритм, который будет выглядеть так:

 function print_table(table): foreach table in database: if table.dependencies.count == 0 print to tableorder.txt if table.dependencies.count > 0 print_table(dependency) //print dependency first end function 

Как вы себе представляете, это связано с большим количеством рекурсии. Я начинаю задаваться вопросом, стоит ли это усилий? Если есть какой-то инструмент? Какой инструмент (или алгоритм) существует для создания списка порядка выполнения отдельных таблиц и представлений .sql с учетом зависимостей? Лучше ли управлять версиями отдельный файл .sql для каждой таблицы / представления или лучше управлять версией всей базы данных в один файл .sql? Я буду признателен за любой ответ, поскольку это заняло много дней. Благодарю.

3 Solutions collect form web for “Контроль версий базы данных для MySQL”

Я не использую MySQL, но, скорее, SQL Server, это как версия моей базы данных:

(Это длинный, но, в конце концов, я надеюсь, что аргументация для меня отказаться от простого дампа схемы, поскольку основной способ обработки версий баз данных становится очевидным.)

  1. Я вношу изменения в схему и применяю ее к тестовой базе данных .

  2. Я генерирую сценарии изменения треугольника и дамп схемы после указанных скриптов. (Я использую ApexSQL, но, вероятно, вам помогут инструменты, специфичные для MySQL).

    1. Сценарии изменения треугольника знают, как перейти от текущей к целевой версии схемы: ALTER TABLE существующий, CREATE TABLE new, DROP VIEW старый. Несколько операций могут возникать в одном и том же файле .SQL, поскольку дельта имеет значение.

    2. Дамп схемы имеет версию целевой схемы: CREATE TABLE a, CREATE VIEW b .. здесь нет «ALTER» или «DROP», поскольку это всего лишь моментальный снимок целевой схемы. Существует один файл .SQL для объекта базы данных, поскольку схема имеет важное значение.

  3. Я использую RoundhousE для применения сценариев изменения дельты. (Я не использую функцию RoundhousE «anytime script», поскольку это неправильно обрабатывает отношения).

Я усердно изучил, что применение изменений схемы базы данных не может быть надежно выполнено без всеобъемлющего поэтапного плана и, аналогично (как указано в вопросе), важны порядок зависимостей отношений . Простое сохранение схемы «текущего» или «конечного» недостаточно. Существует много изменений, которые не могут быть ретроактивно применены A-> C, не зная A-> B-> C, а некоторые изменения B могут включать в себя логику миграции или исправления. Сценарии изменения схемы SQL могут фиксировать эти изменения и позволяют им «переигрывать».

Однако в то же время простое сохранение дельта-скриптов не обеспечивает «простого представления» целевой схемы . Вот почему я также сбрасываю всю схему, а также сценарии изменений и версию. Можно было бы теоретически использовать дамп представления, чтобы построить базу данных, но из-за зависимостей отношений (что очень важно в вопросе) может потребоваться некоторая работа, и я не использую ее как часть автоматического подхода к восстановлению схемы: тем не менее, сохранение части дампа схемы контроля версий Hg позволяет быстро идентифицировать изменения и просматривать целевую схему в конкретной версии.

Изменения дельта, таким образом, продвигаются вперед через ревизии, в то время как дамп схемы дает представление в текущей ревизии. Поскольку дельта изменения являются инкрементальными и только форвардными, важно, чтобы ветвь имела дело с этими изменениями «чистыми», что легко сделать с Hg.

В одном из моих проектов в настоящее время я нахожусь в базе данных № 70 – и счастлив и продуктивен! – после переключения на эту настройку. (И это развернутые изменения, а не только изменения в развитии!)

Счастливое кодирование.

Я не уверен, насколько хорошо это отвечает на ваш вопрос, но я обычно использую mysqldump (часть стандартной установки). Это дает мне sql для создания таблиц и заполнения их, эффективно сериализуя базу данных. Пример:

 > mysqldump -u username -p yourdatabase > database_dump.sql 

Чтобы загрузить базу данных из файла sql dump:

mysql -u username -p -e "source /path/to/database_dump.sql"

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

Вы можете использовать sqitch . Вот учебник для MySql , но на самом деле он агностик.

Изменения выполняются как скрипты, родные для выбранного вами механизма базы данных … Изменения в базе данных могут объявлять зависимости от других изменений – даже при изменениях от других проектов Sqitch. Это гарантирует правильный порядок выполнения, даже если вы внесли изменения в ваш VCS из-за порядка … Изменение развертывания управляется путем сохранения файла плана. Таким образом, нет необходимости указывать свои изменения, хотя вы можете, если хотите. Sqitch не заботится о том, как вы называете свои изменения … Пока вы не помечаете и не выпускаете приложение, вы можете изменять сценарии развертывания изменений так часто, как вам нравится. Они не заблокированы только потому, что они были привязаны к вашей VCS. Это позволяет использовать итеративный подход к разработке схемы базы данных. Или, лучше, вы можете сделать тестовую разработку баз данных.

  • PyQt4 QSqlTableModel, прерывистое обновление QTableView
  • Установка mysql-python на Centos
  • В Django, как создавать таблицы из файла SQL при запуске syncdb
  • Ошибка инструкции UPDATE - MySQLdb / Python
  • Лучший способ денормализации данных в Django?
  • SQLAlchemy: вставка результатов запроса в другую таблицу
  • SQLAlchemy DELETE Ошибка, вызванная наличием как ленивой нагрузки, так и динамической версии того же отношения
  • Python / PyQT QString не будет вставляться в базу данных MySQL
  • Python - лучший язык программирования в мире.