Управление версиями базы данных противсценарии изменения схемы
-
15-09-2020 - |
Вопрос
Создание и поддержание базы данных, которая затем истощается / дорабатывается многими разработчиками, - это то, что происходит при разработке программного обеспечения постоянно.Мы создаем сценарий сборки и поддерживаем дальнейшие сценарии обновления, которые применяются по мере роста базы данных с течением времени.Есть много способов управлять этим, от ручного обновления до консольных приложений / сценариев сборки, которые помогают автоматизировать эти процессы.
Кто-нибудь, кто создавал / управлял этими процессами, перешел на решение для управления версиями для управления схемой базы данных?Если да, то какое решение они сочли наилучшим?Есть ли какие-то подводные камни, которых следует избегать?
Red Gate, похоже, крупный игрок в мире MSSQL, и их система управления версиями БД выглядит очень интересно:http://www.red-gate.com/products/solutions_for_sql/database_version_control.htm
Хотя не похоже, что он заменяет процесс управления данными * по умолчанию, поэтому он заменяет только половину процесса управления изменениями из моего pov.
(когда я говорю о данных, я имею в виду значения поиска и тому подобное, данные, которые должны быть развернуты по умолчанию или в сценарии DR)
Мы работаем в среде .Net / MSSQL, но я уверен, что предпосылка одинакова для всех языков.
Решение
Похожие Вопросы
Один или несколько из этих существующих вопросов могут оказаться полезными:
- Лучший способ управлять изменениями в базе данных
- Отслеживание изменений в базе данных MySQL
- Рекомендации по организации рабочего процесса изменения базы данных SQL Server
- Проверка изменений в базе данных (контроль версий)
- Перенос изменений из базы данных разработчиков в производственную базу данных
- отслеживание изменений, внесенных в структуру базы данных
Или поиск Изменение базы данных
Другие советы
Я слежу за хранилищем данных, разработанным собственными силами банка, в котором я работаю.Это требует постоянного обновления, и у нас есть команда из 2-4 разработчиков, работающих над этим.
Нам повезло, потому что существует только один экземпляр нашего "продукта", поэтому нам не нужно обслуживать развертывание в нескольких экземплярах, которые могут быть разных версий.
Мы храним файл сценария создания для каждого объекта (таблицы, представления, индекса, хранимой процедуры, триггера) в базе данных.
Мы избегаем использования ALTER TABLE
всякий раз, когда это возможно, предпочитая переименовывать таблицу, создайте новую и перенесите данные поверх нее.Это означает, что нам не нужно просматривать историю ALTER
скрипты - мы всегда можем увидеть актуальную версию каждой таблицы, просмотрев ее сценарий создания.Миграция выполняется с помощью отдельного сценария миграции - он может быть частично сгенерирован автоматически.
Каждый раз, когда мы делаем релиз, у нас есть скрипт, который запускает скрипты создания / миграции в соответствующем порядке.
К ТВОЕМУ сведению:Мы используем Visual SourceSafe (фу!) для управления исходным кодом.
Я искал инструмент управления версиями SQL Server и наткнулся на множество премиум-версий, которые выполняют эту работу, используя SQL Server Management Studio в качестве плагина.
LiquiBase является бесплатной, но я так и не смог заставить ее работать для моих нужд.
Однако существует еще один бесплатный продукт, который работает отдельно от SSMS и записывает объекты и данные в плоский файл.
Затем эти объекты могут быть перенесены в новый экземпляр SQL Server, который затем повторно создаст объекты базы данных.
Видишь gitSQL
Может быть, вы напрашиваетесь на Ликвидационная база?