Запуск с управления версиями mysql схемы без излишества. Хорошие решения?

Simple way for a small company: dump your database to SQL and add it to your repository. Then every time you change something, add the changes in the dump file.

You can then use diff to see changes between versions, not to mention have comments explaining your changes. This will also make you virtually immune to MySQL upgrades.

The one downside I've seen to this is that you have to remember to manually add the SQL to your dumpfile. You can train yourself to always remember, but be careful if you work with others. Missing an update could be a pain later on.

This could be mitigated by creating some elaborate script to do it for you when submitting to subversion but it's a bit much for a one man show.

Edit: In the year that's gone by since this answer, I've had to implement a versioning scheme for MySQL for a small team. Manually adding each change was seen as a cumbersome solution, much like it was mentioned in the comments, so we went with dumping the database and adding that file to version control.

What we found was that test data was ending up in the dump and was making it quite difficult to figure out what had changed. This could be solved by dumping the schema only, but this was impossible for our projects since our applications depended on certain data in the database to function. Eventually we returned to manually adding changes to the database dump.

Not only was this the simplest solution, but it also solved certain issues that some versions of MySQL have with exporting/importing. Normally we would have to dump the development database, remove any test data, log entries, etc, remove/change certain names where applicable and only then be able to create the production database. By manually adding changes we could control exactly what would end up in production, a little at a time, so that in the end everything was ready and moving to the production environment was as painless as possible.

Там, где я работаю, у нас есть скрипт установки для каждой новой версии приложения, в котором есть sql, который нам нужно запустить для обновления. Это работает достаточно хорошо для 6 разработчиков с некоторыми ветвлениями для выпусков обслуживания. Мы рассматриваем возможность перехода на Auto Patch http://autopatch.sourceforge.net/ , который решает, какие исправления применить к любой обновляемой базе данных. Похоже, что есть небольшие сложности с обработкой ветвления с помощью Auto Patch, но, похоже, это не будет проблемой для вас.

Как насчет файла управления версиями, созданного таким образом:

mysqldump --no-data database > database.sql

я думаю, что пакетный файл похож это должно делать работу (не пытаясь сильно) ...

mysqldump --no-data -ufoo -pbar имя_базы> путь / к / app / schema.sql
svn commit path / to / app / schema.sql

просто запустите пакетный файл после изменения схемы или позвольте cron / scheduler сделать это (но я не знаю ... я думаю, что коммит работает, если только метки времени изменились, даже если их содержимое одинаково. Не знаю, будет ли это проблемой.)

В нашей компании мы сделали это следующим образом:

Мы поместили все объекты таблиц / БД в их собственный файл, как tbl_Foo.sql . Файлы содержат несколько «частей», разделенных

-- part: create

, где create - это просто описательная идентификация для данной части, файл выглядит так:

-- part: create
IF not exists ...
CREATE TABLE tbl_Foo ...
-- part: addtimestamp
IF not exists ...
BEGIN
   ALTER TABLE ...
END

Затем у нас есть файл XML, который ссылается на каждый часть, которую мы хотим выполнить, когда мы обновляем базу данных до новой схемы. Это выглядит примерно так:

<playlist>
   <classes>
     <class name="table" desc="Table creation" />
     <class name="schema" desc="Table optimization" />
   </classes>
   <dbschema>
      <steps db="a_database">
         <step file="tbl_Foo.sql" part="create" class="table" />
         <step file="tbl_Bar.sql" part="create" class="table" />
      </steps>
      <steps db="a_database">
         <step file="tbl_Foo.sql" part="addtimestamp" class="schema" />
      </steps>
   </dbschema>          
</playlist>

часть if для GUI и с предназначена для раздел меняется. : s выполняются последовательно. У нас есть некоторые другие объекты, такие как sqlclr , которые выполняют разные вещи, такие как развертывание двоичных файлов, но это в значительной степени так.

Конечно, у нас есть компонент, который принимает этот файл списка воспроизведения и объект ресурса / файловой системы, который создает перекрестные ссылки на список воспроизведения и извлекает нужные части, а затем запускает их как администратор в базе данных.

Так как «части» в .sql записаны так, что они могут выполняться в любой версии БД, мы можем запустить все части в каждой предыдущей / более старую версию БД и измените ее, чтобы она была текущей. Конечно, есть некоторые случаи, когда SQL-сервер анализирует имена столбцов «рано», и мы должны позже изменить части, чтобы они стали exec_sql s, но это случается не часто.

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

/__DB
—-/changesets
——–/1123
—-/data
—-/tables

Теперь, кто все это работает то, что у вас есть 3 папки: Столы Содержит таблицу создания запроса. Я рекомендую использовать имя «table_name.sql».

Data Содержит таблицу вставки данных запроса. Я рекомендую использовать то же имя «table_name.sql». Примечание. Не всем таблицам нужен файл данных, вы должны добавить только те, которым нужны эти начальные данные при установке проекта.

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

Мне нравится добавлять их сгруппированные в таблицы с именем xx_tablename .sql - xx - это число, которое указывает порядок, в котором они должны быть запущены, поскольку иногда вам нужно, чтобы модификация выполнялась в определенном порядке.

Примечание: Когда вы изменяете таблицу, вы также добавляете эти изменения в файлы таблиц и данных… поскольку это файлы, которые будут использоваться для новой установки.

Это основная идея.

Для получения более подробной информации вы можете проверьте это сообщение в блоге

Я делаю что-то подобное Маносу, за исключением того, что у меня есть «главный» файл (master.sql), который я обновляю с некоторой регулярностью (раз в 2 месяца). Затем для каждого изменения я создаю версию с именем .sql файл с изменениями. Таким образом, я могу начать с master.sql и добавлять каждую версию с именем .sql, пока я не дойду до текущей версии, и я могу обновлять клиентов, используя версию с именем .sql files, чтобы упростить задачу.

Взгляните на SchemaSync . Он сгенерирует сценарии исправления и возврата (файлы .sql), необходимые для миграции и версии вашей схемы базы данных с течением времени. Это утилита командной строки для MySQL, не зависящая от языка и инфраструктуры.

Наше решение - MySQL Workbench. Мы регулярно реконструируем существующую базу данных в Модель с соответствующим номером версии. Затем можно легко выполнять различия между версиями по мере необходимости. Кроме того, мы получаем красивые диаграммы EER и т. Д.

Несколько месяцев назад я искал инструмент для версионирования схемы MySQL. Я нашел много полезных инструментов, таких как Doctrine migration, RoR migration, некоторые инструменты, написанные на Java и Python.

Но ни один из них не удовлетворял моим требованиям.

Мои требования:

1. Никаких требований, кроме PHP и MySQL
2. Никаких файлов конфигурации схемы, как schema.yml в Doctrine
3. Возможность читать текущую схему из соединения и создавать новый скрипт миграции, чем представлять идентичную схему в других установках приложения.

Я начал писать свой инструмент миграции, и сегодня у меня есть бета-версия.

Пожалуйста, попробуйте ее, если вам интересна эта тема. Пожалуйста, присылайте мне будущие запросы и сообщения об ошибках.

Исходный код: bitbucket.org/idler/mmp/src Обзор на английском языке: bitbucket.org/idler/mmp/wiki/Home Обзор на русском: antonoff.info/development/mysql-migration-with-php-project