Начиная с версии mysql schemata без переполнения. Хорошие решения?

Question

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

Я в основном одна компания, и недавно я даже не использовал контроль версий для своего кода. Я нахожусь в среде Windows, используя Aptana (IDE) и SVN (с черепахой). Я работаю над проектами PHP/mysql.

Что такое эффективный и достаточный (без переполнения) способ версии моей схемы баз данных?

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

Моментальное решение: На данный момент я решил, что я просто сделаю дамп схемы плюс один с необходимыми исходными данными всякий раз, когда я собираюсь зафиксировать тег (стабильная версия). Мне кажется, этого достаточно для меня на текущем этапе. [/ Edit]

[edit2] plus Теперь я также использую третий файл с именем increments.sql, где я вносил все изменения с датами и т. Д. позволяют легко отслеживать историю изменений в одном файле. время от времени я интегрирую изменения в два других файла и пустые increments.sql [/ edit]

Answer 1

Я думаю, что этот вопрос заслуживает современного ответа, поэтому я собираюсь дать его самому. Когда я написал вопрос в 2009 году, я не думаю, что Phinx уже существует, и, безусловно, Laravel этого не сделал.

Сегодня ответ на этот вопрос очень ясен: напишите инкрементные сценарии миграции БД, каждый из которых имеет метод up и down и запускает все эти сценарии или их дельту при установке или обновлении вашего приложения. И, очевидно, добавьте сценарии миграции в свой VCS.

Как уже упоминалось в начале, в мире PHP есть отличные инструменты, которые помогут вам легко управлять своими перемещениями. В Laravel встроены DB-миграции, в том числе соответствующие команды оболочки. У всех остальных есть аналогичное мощное агностическое решение с Phinx.

Обе миграции ремесленников (Laravel) и Phinx работают одинаково. Для каждого изменения в БД, создайте новую миграцию, используйте простой SQL или встроенный построитель запросов, чтобы написать методы вверх и вниз и запустить artisan migrate соответственно. phinx migrate в консоли.

Answer 2

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

Затем вы можете использовать diff, чтобы видеть изменения между версиями, не говоря уже о комментариях, объясняющих ваши изменения. Это также сделает вас практически невосприимчивыми к обновлениям MySQL.

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

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

Редактировать: В течение года, прошедшего с этого ответа, мне пришлось реализовать схему управления версиями для MySQL для небольшой команды. Вручное добавление каждого изменения было рассмотрено как громоздкое решение, как и в комментариях, поэтому мы пошли с демпингом базы данных и добавили этот файл в контроль версий.

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

Это было не просто простейшее решение, но оно также решило некоторые проблемы, с которыми сталкиваются некоторые версии MySQL при экспорте/импорте. Обычно нам приходится удалять базу данных разработки, удалять любые тестовые данные, записи журналов и т. Д., Удалять/изменять определенные имена там, где это применимо, и только затем иметь возможность создавать производственную базу данных. Ручным добавлением изменений мы могли бы точно контролировать, что будет в производстве, немного за раз, чтобы в конце все было готово и переход в производственную среду был настолько безболезненным, насколько это возможно.

Answer 3

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

mysqldump --no-data database > database.sql 

Answer 4

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

Answer 5

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

mysqldump --no-data -ufoo -pbar dbname > path/to/app/schema.sql
svn commit path/to/app/schema.sql

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

Answer 6

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

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

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

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

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

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

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

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

для получения более подробной информации вы можете проверить это blog post

Answer 7

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

Мы складываем все таблицы/объекты БД в их собственном файле, как 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> 

<classes/> часть, если для графического интерфейса пользователя, и <dbschema/> с <steps/> является разделение изменений. Строки <step/>: s выполняются последовательно. У нас есть некоторые другие объекты, такие как sqlclr, чтобы делать разные вещи, такие как разворачивание двоичных файлов, но это в значительной степени.

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

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

Answer 8

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

Answer 9

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

Answer 10

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

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

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

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

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

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

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

Answer 11

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