Механизмы отслеживания изменений схемы БД [закрыто]

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

многие популярные программные пакеты включают сценарии автоматического обновления, которые обнаруживают версию БД и применяют необходимые изменения. Это лучший способ сделать это даже в большем масштабе (в нескольких проектах, а иногда и в нескольких средах и языках)? Если да, то есть ли какой-либо существующий код, который упрощает процесс или лучше всего просто свернуть наше собственное решение? Кто-нибудь реализовал что-то подобное раньше и интегрировал его в Subversion post-commit hooks, или это плохая идея?

хотя решение, поддерживающее несколько платформ, было бы предпочтительнее, нам определенно нужно поддерживать стек Linux/Apache/MySQL/PHP, поскольку большая часть нашей работы находится на этой платформе.

20 ответов


в мире Rails существует концепция миграции, скрипты, в которых изменения в базе данных вносятся в Ruby, а не специфичный для базы данных вкус SQL. Ваш код миграции Ruby в конечном итоге преобразуется в DDL, специфичный для вашей текущей базы данных; это делает переключение платформ баз данных очень легким.

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

это руководство Oracle по миграции Rails охватывает миграции довольно хорошо.

разработчики, использующие другие языки посмотрел миграции и реализовали свои собственные языковые версии. Я знаю о Ruckusing, система миграции PHP, которая моделируется после миграции Rails; это может быть то, что вы ищете.


мы используем что-то похожее на bcwoord, чтобы синхронизировать наши схемы базы данных на 5 различных установках (производство, постановка и несколько установок разработки) и резервное копирование в управлении версиями, и это работает довольно хорошо. Я немного уточню:


для синхронизации структуры базы данных у нас есть один скрипт, update.php и ряд файлов под номером 1.в SQL, 2.по SQL, 3.SQL и др. Скрипт использует одну дополнительную таблицу для хранения текущего номера версии база данных. Файлы N. sql создаются вручную, чтобы перейти от версии (N-1) к версии N базы данных.

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

скрипт обновления работает так:

  • подключиться к база данных.
  • сделайте резервную копию текущей базы данных (потому что stuff будет go wrong) [mysqldump].
  • создайте таблицу бухгалтерского учета (называемую _meta), если она не существует.
  • прочитайте текущую версию из таблицы _meta. Предположим 0, если не найден.
  • для всех .файлы sql пронумерованы выше версии, выполните их по порядку
  • если один из файлов вызвал ошибку: откат в резервную копию
  • в противном случае, обновите версию в таблице бухгалтерского учета до самой высокой .sql-файл выполнен.

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

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


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

остерегайтесь при вставке запросов от phpMyAdmin, хотя! эти сгенерированные запросы обычно включают имя базы данных, которое вы определенно не хотите, так как это нарушит ваши скрипты! Что-то вроде CREATE TABLE mydb.newtable(...) произойдет сбой, если база данных в системе не называется mydb. Мы создали предварительный комментарий SVN hook, который будет запрещать.файлы sql, содержащие mydb string, что является верным признаком того, что кто-то копирует/вставляет из phpMyAdmin без надлежащей проверки.


моя команда скрипты все изменения базы данных, и фиксирует эти скрипты в SVN, вместе с каждым выпуском приложения. Это позволяет осуществлять инкрементные изменения базы данных без потери каких-либо данных.

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


проблема здесь действительно делает его легким для разработчиков, чтобы написать свои собственные локальные изменения в систему управления версиями, чтобы поделиться с командой. Я сталкивался с этой проблемой в течение многих лет и был вдохновлен функциональностью Visual Studio для профессионалов баз данных. Если вам нужен инструмент с открытым исходным кодом с теми же функциями, попробуйте следующее:http://dbsourcetools.codeplex.com/ Повеселись, - Натан.


Если вы все еще ищете решения : мы предлагаем инструмент под названием neXtep дизайнер. Это среда разработки базы данных, с которой вы можете поместить всю свою базу данных под контроль версий. Вы работаете в репозитории с управлением версиями, где можно отслеживать каждое изменение.

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

тогда у вас есть много вариантов : вы можете взять эти скрипты и поместить их в свой SVN с кодом приложения, чтобы он был развернут вашим существующим механизмом. Другой вариант-использовать механизм доставки neXtep: скрипты экспортируются в так называемый "пакет доставки" (SQL scripts + XML descriptor), и установщик может понять этот пакет и развернуть его на целевом сервере, обеспечивая при этом strcutural согласованность, проверку зависимостей, регистрацию установленная версия и т. д.

продукт GPL и основан на Eclipse, поэтому он работает на Linux, Mac и windows. Он также поддерживает Oracle, Mysql и Postgresql на данный момент (поддержка DB2 находится в пути). Посмотрите на wiki, где вы найдете более подробную информацию : http://www.nextep-softwares.com/wiki


сбросьте схему в файл и добавьте ее в систему управления версиями. Тогда простой diff покажет вам, что изменилось.


Скотт Эмблер производит большую серию статей (и соавтор книги) по рефакторингу базы данных, с идеей, что вы должны по существу применять принципы и методы TDD для поддержания вашей схемы. Вы настраиваете серию тестов структуры и исходных данных для базы данных. Затем, прежде чем что-либо изменить, вы изменяете/пишете тесты, чтобы отразить это изменение.

мы делаем это уже некоторое время, и это, кажется, работает. Мы написали код для генерации основных имя столбца и тип данных проверяются в наборе модульного тестирования. Мы можем перезапустить эти тесты в любое время, чтобы убедиться, что база данных в svn checkout соответствует live db, приложение фактически работает.

Как оказалось, разработчики также иногда настраивают свою базу данных песочницы и пренебрегают обновлением файла схемы в SVN. Затем код зависит от изменения БД, которое не было проверено. Такого рода ошибка может быть безумно трудно определить, но тестовый набор сразу же ее подберет. Это особенно приятно, если вы встроили его в более крупный план непрерывной интеграции.


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

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

с помощью этого скрипта вы можете интегрировать его с DBUnit или каким-то скриптом сборки, поэтому, похоже, он может соответствовать вашим уже автоматизированным процессам.


Если вы используете C#, посмотрите на дозвуковой, очень полезный инструмент ORM, но также генерирует SQL-скрипт для воссоздания вашей схемы и\или данных. Затем эти сценарии можно поместить в систему управления версиями.

http://subsonicproject.com/


У К. Скотта Аллена есть приличная статья или две о версионировании схемы, которая использует концепцию инкрементных сценариев обновления / миграции, на которую ссылаются в других ответах здесь; см. http://odetocode.com/Blogs/scott/archive/2008/01/31/11710.aspx.


Я использовал следующую структуру проекта базы данных в Visual Studio для нескольких проектов, и она работала довольно хорошо:

база данных

Сценарии Изменения

0.Развернуть.в SQL

1.SchemaChanges.в SQL

2.DataChanges.в SQL

3.Разрешения.в SQL

Создать Скрипты

хранимые процедуры

функции

вид

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

1.Развернуть.в SQL

2.SchemaChanges.в SQL

содержимое папки Create Scripts

2.DataChanges.в SQL

3.Разрешения.в SQL

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


мы используем очень простое, но эффективное решение.

для новых установок у нас есть метаданные.sql-файл в репозитории, который содержит всю схему БД, затем в процессе сборки мы используем этот файл для создания базы данных.

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

Так в нашем программное обеспечение у нас есть что-то вроде этого:

RegisterUpgrade(1, 'ALTER TABLE XX ADD XY CHAR(1) NOT NULL;');

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

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

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

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


Я создаю папки с именами версий сборки и помещаю туда сценарии обновления и понижения. Например, у вас могут быть следующие папки: 1.0.0, 1.0.1 и 1.0.2. Каждый из них содержит скрипт, который позволяет вам обновлять или понижать вашу базу данных между версиями.

Если клиент или клиент позвонит вам с проблемой с версией 1.0.1, и вы используете 1.0.2, возврат базы данных к его версии не будет проблемой.

в базе данных, создайте таблицу под названием "schema", в которую вы поместите текущую версию базы данных. Затем написать программу, которая может повысить или понизить вашу базу данных для вас легко.

Как сказал Джоуи, если вы находитесь в мире Rails, используйте миграции. :)


для моего текущего проекта PHP мы используем идею миграции rails, и у нас есть каталог миграции, в котором мы храним название файлов "migration_XX.sql", где XX-номер миграции. В настоящее время эти файлы создаются вручную по мере обновления, но их создание может быть легко изменен.

тогда у нас есть скрипт под названием "Migration_watcher", который, Поскольку мы находимся в pre-alpha, в настоящее время запускается при каждой загрузке страницы и проверяет, есть ли новый migration_XX.файл sql, где XX больше, чем текущая версия миграции. Если это так, он запускает все migration_XX.sql файлы до самого большого числа против базы данных и вуаля! изменения схемы автоматизированы.

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


Я бы рекомендовал использовать Ant (кросс-платформу) для стороны "скриптов" (поскольку он может практически разговаривать с любой БД через jdbc) и Subversion для исходного репозитория. Ant предоставит вам "резервное копирование" вашей БД в локальные файлы перед внесением изменений. 1. резервное копирование существующей схемы БД в файл через Ant 2. управление версиями в репозиторий Subversion через Ant 3. отправить новые операторы sql в БД через Ant


Toad для MySQL имеет функцию schema compare, которая позволяет синхронизировать 2 базы данных. Это лучший инструмент, который я использовал до сих пор.


миграции IMHO имеют огромную проблему:

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

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


мне нравится, как Yii обрабатывает миграции базы данных. Миграция-это в основном PHP-скрипт, реализующий CDbMigration. CDbMigration определяет up метод, содержащий логику миграции. Также возможно реализовать down метод для поддержки реверсирования миграции. Кроме того, safeUp или safeDown можно использовать, чтобы убедиться, что миграция выполняется в контексте транзакции.

инструмент командной строки Yii yiic содержит поддержка создания и выполнения миграции. Миграции могут быть применены или отменены, либо по одному, либо в пакете. Создание миграции приводит к коду для реализации класса PHP CDbMigration, с уникальным именем на основе метки времени и имени миграции, указанного пользователем. Все миграции, ранее примененные к базе данных, хранятся в таблице миграции.

для получения дополнительной информации см. Перенос Базы Данных статья из руководства.


попробуйте db-deploy-в основном инструмент Java, но работает и с php.


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