Начиная с версии MySQL схемы без перебора. Хорошие решения? - PullRequest
7 голосов
/ 16 апреля 2009

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

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

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

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

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

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

Ответы [ 11 ]

7 голосов
/ 16 апреля 2009

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

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

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

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

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

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

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

2 голосов
/ 16 апреля 2009

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

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

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

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

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

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

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

Это главная идея.

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

2 голосов
/ 16 апреля 2009

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

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

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

2 голосов
/ 16 апреля 2009

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

2 голосов
/ 16 апреля 2009

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

mysqldump --no-data database > database.sql
1 голос
/ 13 марта 2015

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

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

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

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

1 голос
/ 08 июля 2010

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

1 голос
/ 08 июля 2010

Несколько месяцев назад я искал инструмент для создания версий схемы MySQL. Я нашел много полезных инструментов, таких как миграция Doctrine, миграция RoR, некоторые инструменты, написанные на 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

1 голос
/ 16 апреля 2010

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

1 голос
/ 18 апреля 2009

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

Мы помещаем все объекты таблиц / БД в их собственный файл, например 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/>, если для GUI, и <dbschema/> с <steps/> предназначены для изменения раздела. <step/>: s выполняются последовательно. У нас есть некоторые другие объекты, такие как sqlclr, для выполнения различных задач, таких как развертывание бинарных файлов, но это почти все.

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

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

...