Как вы делаете версию и синхронизируете свою модель данных MySQL? - PullRequest
Новая
       44

Как вы делаете версию и синхронизируете свою модель данных MySQL?

0 голосов
/ 21 ноября 2010

Каков наилучший способ сохранить мою модель данных MySQL и автоматически применить изменения к моему серверу базы данных разработки по мере их внесения (или, по крайней мере, ночью)?

Например, сегодня я работаю над своим проектоми создайте эту таблицу в моей базе данных и сохраните оператор в файл SQL для последующего развертывания в производство: 

create table dog (
  uid int,
  name varchar(50)
);

И завтра я решу, что хочу записать породу каждой собаки.Поэтому я изменил файл SQL следующим образом: 

create table dog (
  uid int,
  name varchar(50),
  breed varchar(30)
);

Этот сценарий будет работать в производственной среде для первого выпуска, но это не поможет мне обновить мою базу данных разработки, поскольку ERROR 1050 (42S01): Table 'dog' already exists.Кроме того, он не будет работать в производстве, если это изменение было сделано после первого выпуска.Так что мне действительно нужно ALTER таблицу сейчас.

Так что теперь у меня есть две проблемы:

  1. Вот как я должен сохранять свою модель данных (куча операторов createв файле SQL) и
  2. Как применять такие изменения к моей базе данных?

Моя цель - аккуратно отменить изменения и обеспечить непрерывную интеграцию.Я использую инструмент DDLSYNC, который находит и применяет разницу в базе данных Oracle, но я не уверен, какие подобные инструменты существуют для MySQL.

Ответы [ 2 ]

1 голос
/ 21 ноября 2010

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

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

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

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

Восстановление происходит таким образом, что перезаписываются только таблицы, которые были в действующей базе данных. Поэтому любое обновление, которое добавляет таблицу, также должно отвечать только за ее добавление, если оно не существует. DROP TABLE IF EXISTS удобно. К сожалению, не все базы данных поддерживают это, поэтому система обновлений также позволяет выполнять сценарии, написанные на нашем языке по выбору, а не только на SQL.

Все это примерно в 150 строках кода. Это так же просто, как чтение каталога, сравнение содержимого с таблицей и выполнение всего, что еще не было выполнено, в определенном порядке.

0 голосов
/ 21 ноября 2010

Во многих средах для этого есть стандартные инструменты: в Rails есть что-то под названием Миграции , что легко реплицируется в PHP или любом другом подобном языке.

...