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

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

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

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

4.08.2008 21:31:40
20 ОТВЕТОВ
РЕШЕНИЕ

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

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

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

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

56
2.05.2016 09:04:43
Ruckusing FTW - мы адаптировали его к нашей системе БД и вполне довольны.
Piskvor left the building 7.10.2009 15:12:48
Теперь он находится на github: github.com/ruckus/ruckusing-migrations
user409460 29.06.2015 23:00:12

Мы используем что-то похожее на 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 без надлежащей проверки.

50
5.12.2013 15:03:26
Как вы справились со столкновениями? Несколько разработчиков меняют один и тот же элемент в БД, например, хранимую процедуру? Это может произойти, если вы работаете над одной и той же веткой или у вас две линии разработки (две ветки)
Asaf Mesika 20.11.2010 15:04:52
Столкновения были очень редкими; единственное, что произошло на самом деле, это то, что два человека пытались создать один и тот же файл N.sql. Конечно, первый выигрывает, а второй вынужден переименовываться в следующий по величине номер и пытаться снова. У нас не было версии базы данных на ветке, хотя.
rix0rrr 25.11.2010 13:34:42

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

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

12
5.08.2008 19:56:43
как вы записываете все изменения?
Smith 23.05.2017 21:02:52

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

10
7.07.2009 13:26:46

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

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

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

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

10
25.10.2010 05:46:13
Выглядит интересно. Он также имеет интерфейс командной строки или планируется?
Piskvor left the building 25.10.2010 10:46:35

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

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

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

8
29.08.2008 04:51:30

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

7
6.08.2008 16:59:36
Дамп должен быть в SQL, как в mysqldump, дампы Oracle являются двоичными.
Osama Al-Maadeed 20.10.2008 08:20:07
Существует также более фундаментальная проблема с изменением схемы. Как вы отличаете столбец drop + add от переименования столбца. Ответ прост: вы не можете. Это причина, почему вам нужно записывать фактические операции изменения схемы.
psp 1.08.2010 07:24:03
Разница покажет, что один столбец пропал, а другой появился (если у них нет одинакового имени), и в большинстве случаев этого достаточно. Сценарии каждого изменения схемы - это, конечно, хороший способ: в Drupal это обрабатывается, например, специальным хуком.
deadprogrammer 3.08.2010 20:05:02

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

6
29.08.2008 05:11:38

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

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

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

5
4.08.2008 22:28:58
Да, это в значительной степени то, что мы имеем сейчас. К сожалению, это не дает нам простого способа изменить существующие базы данных - сценарий SQL, сгенерированный mysqldump, предполагает, что вы создаете таблицу с нуля (или перезаписываете таблицу, если она существует). Нам нужно что-то более высокотехнологичное, потому что оно должно применить последовательность операторов ALTER TABLE к базе данных, и для того, чтобы сделать это правильно, ему необходимо знать текущее состояние базы данных.
pix0r 4.08.2008 22:32:13

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

http://subsonicproject.com/

5
4.08.2008 22:47:46
Похоже, что на данный момент URL не работает.
Mark Schultheiss 14.02.2013 17:54:56

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

5
8.08.2008 18:31:25

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

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

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

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

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

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

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

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

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

5
21.01.2014 06:33:42

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

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

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

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

4
5.08.2008 04:36:13

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

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

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

3
23.08.2008 12:58:24

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

3
17.09.2008 16:54:23

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

3
5.02.2011 11:08:58

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

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

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

3
25.06.2011 13:18:43

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

3
19.01.2012 01:52:46

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

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

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

2
12.03.2011 14:15:17

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

0
4.11.2009 19:43:11