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

Ответ 1

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

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

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

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

Ответ 2

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

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

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

Обновление script работает следующим образом:

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

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

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

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

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

Ответ 3

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

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

Ответ 4

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

Ответ 5

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

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

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

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

Ответ 6

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

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

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

Ответ 7

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

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

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

Ответ 8

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

http://subsonicproject.com/

Ответ 9

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

Ответ 10

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

Ответ 11

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

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

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

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

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

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

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

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

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

Ответ 12

Я использовал следующую структуру проекта базы данных в 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 в папке "Сменить сценарии" удаляется.

Ответ 13

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

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

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

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

Ответ 14

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

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

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

Ответ 15

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

Ответ 16

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

Ответ 17

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

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

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

Ответ 18

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

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

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

Ответ 19

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

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

Ответ 20

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