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

Question

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

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

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

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

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

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

Answer 1

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

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

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

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

Answer 2

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

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

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

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

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

К ТВОЕМУ сведению:Мы используем Visual SourceSafe (фу!) для управления исходным кодом.

Answer 3

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

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

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

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

Видишь gitSQL

Answer 4

Может быть, вы напрашиваетесь на Ликвидационная база?