Механизмы для изменения схемы отслеживания DB

голоса
128

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

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

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

Задан 04/08/2008 в 22:31
источник пользователем
На других языках...                            


20 ответов

голоса
54

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

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

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

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

Ответил 04/08/2008 d 23:45
источник пользователем

голоса
48

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


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

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

Сценарий обновления работает следующим образом:

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

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

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


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

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

Ответил 22/08/2008 d 15:44
источник пользователем

голоса
11

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

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

Ответил 05/08/2008 d 20:56
источник пользователем

голоса
9

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

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

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

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

Ответил 25/10/2010 d 06:46
источник пользователем

голоса
9

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

Ответил 07/07/2009 d 14:26
источник пользователем

голоса
6

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

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

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

Ответил 29/08/2008 d 05:51
источник пользователем

голоса
6

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

Ответил 06/08/2008 d 17:59
источник пользователем

голоса
5

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

Ответил 29/08/2008 d 06:11
источник пользователем

голоса
5

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

http://subsonicproject.com/

Ответил 04/08/2008 d 23:47
источник пользователем

голоса
5

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

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

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

Ответил 04/08/2008 d 23:28
источник пользователем

голоса
4

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

База данных

Изменение сценариев

0.PreDeploy.sql

1.SchemaChanges.sql

2.DataChanges.sql

3.Permissions.sql

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

Sprocs

функции

Просмотры

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

1.PreDeploy.sql

2.SchemaChanges.sql

Содержание Создать папку Scripts

2.DataChanges.sql

3.Permissions.sql

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

Ответил 08/08/2008 d 19:31
источник пользователем

голоса
4

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

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

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

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

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

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

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

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

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

Ответил 08/08/2008 d 19:21
источник пользователем

голоса
3

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

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

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

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

Ответил 05/08/2008 d 05:36
источник пользователем

голоса
2

Попробуйте DB-Deploy - в основном инструмент Java, но работает с PHP, а также.

Ответил 19/01/2012 d 02:52
источник пользователем

голоса
2

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

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

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

Ответил 25/06/2011 d 14:18
источник пользователем

голоса
2

ИМХО Миграции есть огромная проблема:

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

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

Ответил 12/03/2011 d 15:15
источник пользователем

голоса
2

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

Ответил 05/02/2011 d 12:08
источник пользователем

голоса
2

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

Ответил 17/09/2008 d 17:54
источник пользователем

голоса
2

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

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

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

Ответил 23/08/2008 d 13:58
источник пользователем

голоса
0

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

Ответил 04/11/2009 d 20:43
источник пользователем

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more