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

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

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

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

В мире 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 базы данных.

Их можно использовать для добавления таблиц, добавления столбцов, переноса данных из старого в новый формат столбцов, затем отбрасывания столбца, вставки строк «основных» данных, таких как типы пользователей и т. Д. В принципе, он может делать все что угодно и с надлежащими данными. Скрипты миграции, вы никогда не потеряете данные.

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

• Подключиться к базе данных.
• Сделайте резервную копию текущей базы данных (потому что все пойдет не так) [mysqldump].
• Создайте бухгалтерскую таблицу (называемую _meta), если она не существует.
• Считайте текущую ВЕРСИЮ из таблицы _meta. Предположим, 0, если не найден.
• Для всех файлов .sql с номерами выше VERSION выполните их по порядку
• Если один из файлов выдал ошибку: откат к резервной копии
• В противном случае обновите версию в бухгалтерской таблице до самого высокого выполненного файла .sql.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Если вы используете C #, взгляните на Subsonic, очень полезный инструмент ORM, но он также создает сценарий sql для воссоздания вашей схемы и \ или данных. Эти сценарии могут быть помещены в систему контроля версий.

http://subsonicproject.com/

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

База данных

Изменить сценарии

0.PreDeploy.sql

1.SchemaChanges.sql

2.DataChanges.sql

3.Permissions.sql

Создание сценариев

Sprocs

функции

Просмотры

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

1.PreDeploy.sql

2.SchemaChanges.sql

Содержимое папки «Создание сценариев»

2.DataChanges.sql

3.Permissions.sql

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для получения дополнительной информации см. Статью « Миграция базы данных» из руководства.

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

• http://dbdeploy.com/
• http://davedevelopment.co.uk/2008/04/14/how-to-simple-database-migrations-with-phing-and-dbdeploy.html

ИМХО миграции имеют огромную проблему:

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

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

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