Управление исходным кодом базы данных и сценарии изменения схемы

Question

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

Кто-нибудь, кто создавал / управлял этими процессами, перешел на решение Source Control для управления схемой базы данных? Если да, то как они нашли лучшее решение? Есть ли подводные камни, которых следует избегать?

Red Gate, похоже, является крупным игроком в мире MSSQL, и их управление исходным кодом в БД выглядит очень интересно: http://www.red -gate.com / продукция / solutions_for_sql / database_version_control.htm

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

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

Мы работаем в среде .Net / MSSQL, но я уверен, что предпосылка одинакова для всех языков.

Answer 1

Похожие вопросы

Один или несколько из этих существующих вопросов могут быть полезны:

• Лучший способ управлять изменениями базы данных
• Отслеживание изменений базы данных MySQL
• Рекомендации по работе с изменениями базы данных SQL Server
• Проверка изменений базы данных (контроль версий)
• Перенос изменений из БД разработчика в производственную БД
• отслеживание изменений, внесенных в структуру базы данных

Илипоиск Изменение базы данных

Answer 2

Я искал инструмент управления исходным кодом SQL Server - и наткнулся на множество премиум-версий, которые справляются со своей работой - используя SQL Server Management Studio в качестве плагина.

LiquiBase - бесплатная, ноу меня никогда не получалось, чтобы это работало для моих нужд.

Существует еще один бесплатный продукт, хотя он работает отдельно от SSMS и выводит объекты и данные в плоский файл.

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

См. gitSQL

Answer 3

Я присматриваю за хранилищем данных, разработанным самим банком, в котором я работаю. Это требует постоянного обновления, и у нас работает команда из 2-4 разработчиков.

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

Мы сохраняем файл сценария создания для каждого объекта (таблицы, представления, индекса, хранимой процедуры, триггера) в базе данных.

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

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

К вашему сведению: Мы используем Visual SourceSafe (чёрт!) Для контроля исходного кода.

Answer 4

Может быть, вы просите LiquiBase ?