Управление версиями базы данных SQL Server
Я хочу, чтобы мои базы данных были под контролем версий. У кого-нибудь есть какие-либо советы или рекомендуемые статьи, чтобы начать меня?
Я всегда хочу, чтобы там были хотя бы какие-то данные (как alumb упоминалось: типы пользователей и администраторы). Я также часто хочу большой набор сгенерированных тестовых данных для измерения производительности.
30 ответов
Мартин Фаулер написал мою любимую статью на эту тему, http://martinfowler.com/articles/evodb.html. Я предпочитаю не помещать дампы схемы в систему управления версиями, как это часто бывает, и другие советуют, потому что я хочу простой способ обновить производственную базу данных.
Для веб-приложения, в котором у меня будет один экземпляр производственной базы данных, я использую два метода:
Сценарии обновления базы данных
Сценарии обновления базы данных последовательности, содержащие DDL, необходимый для перемещения схемы из версии N в N+1. (Они идут в вашей системе контроля версий.) Таблица _version_history_, что-то вроде
create table VersionHistory (
Version int primary key,
UpgradeStart datetime not null,
UpgradeEnd datetime
);
получает новую запись каждый раз, когда запускается скрипт обновления, соответствующий новой версии.
Это гарантирует, что легко увидеть, какая версия схемы базы данных существует, и что сценарии обновления базы данных запускаются только один раз. Опять же, это не дампы базы данных. Скорее, каждый скрипт представляет изменения, необходимые для перехода от одной версии к другой. Это сценарий, который вы применяете к своей производственной базе данных, чтобы "обновить" ее.
Синхронизация Sandbox разработчика
- Скрипт для резервного копирования, очистки и сокращения рабочей базы данных. Запускайте это после каждого обновления производственной БД.
- Скрипт для восстановления (и при необходимости подстройки) резервной копии на рабочей станции разработчика. Каждый разработчик запускает этот скрипт после каждого обновления производственной БД.
Предостережение: мои автоматизированные тесты выполняются на базе правильной схемы, но пустой базы данных, поэтому этот совет не будет полностью соответствовать вашим потребностям.
Продукт SQL Gate от Red Gate не только позволяет выполнять сравнения на уровне объектов и генерировать из них сценарии изменений, но также позволяет экспортировать объекты базы данных в иерархию папок, упорядоченную по типу объекта, с одним созданием [objectname].sql. скрипт на объект в этих каталогах. Иерархия типов объектов выглядит следующим образом:
\ Функции
\Безопасность
\ Security \ Роли
\ Security \ Schemas
\ Security \ Users
\Хранимые процедуры
\Tables
Если вы вносите свои сценарии в тот же корневой каталог после внесения изменений, вы можете использовать это для обновления репозитория SVN и ведения истории выполнения каждого объекта в отдельности.
Это одна из "трудных проблем" развития. Насколько я знаю, нет идеальных решений.
Если вам нужно только сохранить структуру базы данных, а не данные, вы можете экспортировать базу данных в виде запросов SQL. (в Enterprise Manager: щелкните правой кнопкой мыши на базе данных -> Создать сценарий SQL. Я рекомендую установить "создать один файл на объект" на вкладке параметров). Затем вы можете зафиксировать эти текстовые файлы в svn и использовать функции svn diff и logging.
Я связал это с Batch-скриптом, который принимает пару параметров и устанавливает базу данных. Я также добавил несколько дополнительных запросов, которые вводят данные по умолчанию, такие как типы пользователей и администратор. (Если вам нужна дополнительная информация по этому вопросу, опубликуйте что-нибудь, и я смогу разместить сценарий где-нибудь доступным)
Если вам также необходимо сохранить все данные, я рекомендую сохранить резервную копию базы данных и использовать продукты Redgate ( http://www.red-gate.com/) для сравнения. Они не дешевы, но они стоят каждого пенни.
Во-первых, вы должны выбрать систему контроля версий, которая подходит именно вам:
Централизованная система контроля версий - стандартная система, в которой пользователи регистрируются / регистрируются до / после работы с файлами, а файлы хранятся на одном центральном сервере.
Распределенная система контроля версий - система, в которой репозиторий клонируется, и каждый клон фактически является полной резервной копией репозитория, поэтому в случае сбоя любого сервера любой клонированный репозиторий можно использовать для его восстановления. После выбора подходящей системы для ваших нужд вам нужно будет установить репозиторий, который является ядром каждой системы контроля версий. Все это объясняется в следующей статье: http://solutioncenter.apexsql.com/sql-server-source-control-part-i-understanding-source-control-basics/
После настройки репозитория, а также в случае, когда центральная система контроля версий - рабочая папка, вы можете прочитать эту статью. В нем показано, как настроить управление исходным кодом в среде разработки с помощью:
SQL Server Management Studio через поставщика MSSCCI,
Visual Studio и инструменты данных SQL Server
- Сторонний инструмент ApexSQL Source Control
Здесь, в Red Gate, мы предлагаем инструмент SQL Source Control, который использует технологию SQL Compare для связи вашей базы данных с репозиторием TFS или SVN. Этот инструмент интегрируется в SSMS и позволяет вам работать как обычно, за исключением того, что теперь он позволяет фиксировать объекты.
Для подхода на основе миграции (более подходящего для автоматических развертываний) мы предлагаем SQL Change Automation (ранее называлась ReadyRoll), которая создает и управляет набором инкрементных сценариев как проект Visual Studio.
В SQL Source Control можно указывать статические таблицы данных. Они хранятся в системе контроля версий как операторы INSERT.
Если вы говорите о тестовых данных, мы рекомендуем вам либо создавать тестовые данные с помощью инструмента, либо с помощью заданного вами сценария после развертывания, либо просто восстанавливать производственную резервную копию в среду разработки.
Возможно, вы захотите взглянуть на Liquibase ( http://www.liquibase.org/). Даже если вы не используете сам инструмент, он достаточно хорошо справляется с концепциями управления изменениями базы данных или рефакторинга.
+1 для всех, кто порекомендовал инструменты RedGate, с дополнительной рекомендацией и предупреждением.
SqlCompare также имеет прилично документированный API: так что вы можете, например, написать консольное приложение, которое синхронизирует вашу папку сценариев с контролируемым исходным кодом с базой данных тестирования интеграции CI при регистрации, чтобы, когда кто-то регистрирует изменение схемы из папки скриптов он автоматически развертывается вместе с соответствующим изменением кода приложения. Это помогает сократить разрыв с разработчиками, которые забывают о распространении изменений в своих локальных БД на общую БД разработки (я думаю, около половины из нас:)).
Предостережение заключается в том, что с помощью скриптового решения или иным образом инструменты RedGate достаточно гладкие, поэтому легко забыть о реалиях SQL, лежащих в основе абстракции. Если вы переименуете все столбцы в таблице, SqlCompare не сможет сопоставить старые столбцы с новыми столбцами и отбросит все данные в таблице. Он будет генерировать предупреждения, но я видел, как люди проходили мимо. Думаю, здесь есть общий момент, который стоит отметить, что до сих пор можно автоматизировать только версионирование и обновление БД - абстракции очень неплотные.
В VS 2010 используйте проект базы данных.
- Сценарий вашей базы данных
- Внесите изменения в сценарии или непосредственно на вашем сервере БД
- Синхронизация с использованием Data > Schema Compare
Создает идеальное решение для управления версиями БД и упрощает синхронизацию БД.
Мы используем DBGhost для управления нашей базой данных SQL. Затем вы помещаете свои скрипты для создания новой базы данных в свой контроль версий, и он либо создает новую базу данных, либо обновляет любую существующую базу данных до схемы в управлении версиями. Таким образом, вам не нужно беспокоиться о создании сценариев изменений (хотя вы все равно можете это сделать, если, например, вы хотите изменить тип данных столбца и вам необходимо преобразовать данные).
Это хороший способ сохранить сценарии базы данных в системе управления версиями с помощью сценариев изменений, чтобы вы могли обновить любую имеющуюся базу данных. Также вы можете сохранить схемы для разных версий, чтобы создать полную базу данных без применения всех сценариев изменений. Обработка сценариев должна быть автоматизирована, чтобы вам не приходилось выполнять ручную работу.
Я думаю, что важно иметь отдельную базу данных для каждого разработчика и не использовать общую базу данных. Таким образом, разработчики могут создавать тестовые случаи и этапы разработки независимо от других разработчиков.
Инструмент автоматизации должен иметь средства для обработки метаданных базы данных, которые сообщают, какие базы данных находятся в каком состоянии разработки, а какие таблицы содержат данные, контролируемые версиями, и так далее.
Вы также можете посмотреть на решение по миграции. Это позволяет вам указать схему вашей базы данных в коде C# и прокрутить версию базы данных вверх и вниз с помощью MSBuild.
В настоящее время я использую DbUp, и он работает хорошо.
Вы не упомянули какие-либо особенности вашей целевой среды или ограничений, поэтому это может быть не совсем применимо... но если вы ищете способ эффективно отслеживать развивающуюся схему БД и не противостоите идее использования Рубин, миграции ActiveRecord прямо на вашей аллее.
Миграции программно определяют преобразования базы данных с использованием Ruby DSL; каждое преобразование может применяться или (обычно) откатываться, что позволяет вам переходить к другой версии схемы БД в любой момент времени. Файл, определяющий эти преобразования, может быть зарегистрирован в системе контроля версий, как и любой другой фрагмент исходного кода.
Поскольку миграции являются частью ActiveRecord, они обычно находят применение в полнофункциональных приложениях Rails; однако вы можете использовать ActiveRecord независимо от Rails с минимальными усилиями. Смотрите здесь для более подробной обработки использования миграций AR за пределами Rails.
Каждая база данных должна находиться под контролем исходного кода. Чего не хватает, так это инструмента для автоматической записи всех объектов базы данных и "данных конфигурации" в файл, который затем можно добавить в любую систему управления версиями. Если вы используете SQL Server, то мое решение здесь: http://dbsourcetools.codeplex.com/. Повеселись. Натан.
Это просто.
Когда базовый проект готов, вы должны создать полный скрипт базы данных. Этот скрипт передан в SVN. Это первая версия.
После этого все разработчики создают сценарии изменений (ALTER..., новые таблицы, sprocs и т. Д.).
Когда вам нужна текущая версия, вы должны выполнить все новые сценарии изменений.
Когда приложение выпущено в производство, вы возвращаетесь к 1 (но, конечно, это будет последовательная версия).
Nant поможет вам выполнить эти сценарии изменений.:)
И запомни. Все отлично работает, когда есть дисциплина. Каждый раз, когда происходит изменение базы данных, соответствующие функции в коде также фиксируются.
Поскольку наше приложение должно работать в нескольких СУБД, мы сохраняем определение нашей схемы в системе управления версиями, используя нейтральный для базы данных формат крутящего момента (XML). Мы также контролируем версию справочных данных для нашей базы данных в формате XML следующим образом (где "Отношение" является одной из справочных таблиц):
<Relationship RelationshipID="1" InternalName="Manager"/>
<Relationship RelationshipID="2" InternalName="Delegate"/>
etc.
Затем мы используем собственные инструменты для создания сценариев обновления схемы и справочных данных, которые требуются для перехода от версии X базы данных к версии X + 1.
Если у вас небольшая база данных и вы хотите создать версию для всего этого, этот пакетный скрипт может помочь. Он отсоединяет, сжимает и проверяет файл MDF базы данных MSSQL в Subversion.
Если вы в основном хотите создать версию своей схемы и иметь небольшой объем справочных данных, вы можете использовать SubSonic Migrations для этого. Преимущество в том, что вы можете легко перейти вверх или вниз к любой конкретной версии.
Чтобы сделать дамп в систему управления исходным кодом немного быстрее, вы можете увидеть, какие объекты изменились с прошлого раза, используя информацию о версии в sysobjects.
Настройка: Создайте таблицу в каждой базе данных, которую вы хотите проверять постепенно, чтобы хранить информацию о версии с момента последней проверки (пусто при первом запуске). Очистите эту таблицу, если хотите пересмотреть всю структуру данных.
IF ISNULL(OBJECT_ID('last_run_sysversions'), 0) <> 0 DROP TABLE last_run_sysversions
CREATE TABLE last_run_sysversions (
name varchar(128),
id int, base_schema_ver int,
schema_ver int,
type char(2)
)
Нормальный режим работы: вы можете взять результаты из этого sql, и сгенерировать sql-скрипты только для тех, которые вас интересуют, и поместить их в систему управления исходным кодом по вашему выбору.
IF ISNULL(OBJECT_ID('tempdb.dbo.#tmp'), 0) <> 0 DROP TABLE #tmp
CREATE TABLE #tmp (
name varchar(128),
id int, base_schema_ver int,
schema_ver int,
type char(2)
)
SET NOCOUNT ON
-- Insert the values from the end of the last run into #tmp
INSERT #tmp (name, id, base_schema_ver, schema_ver, type)
SELECT name, id, base_schema_ver, schema_ver, type FROM last_run_sysversions
DELETE last_run_sysversions
INSERT last_run_sysversions (name, id, base_schema_ver, schema_ver, type)
SELECT name, id, base_schema_ver, schema_ver, type FROM sysobjects
-- This next bit lists all differences to scripts.
SET NOCOUNT OFF
--Renamed.
SELECT 'renamed' AS ChangeType, t.name, o.name AS extra_info, 1 AS Priority
FROM sysobjects o INNER JOIN #tmp t ON o.id = t.id
WHERE o.name <> t.name /*COLLATE*/
AND o.type IN ('TR', 'P' ,'U' ,'V')
UNION
--Changed (using alter)
SELECT 'changed' AS ChangeType, o.name /*COLLATE*/,
'altered' AS extra_info, 2 AS Priority
FROM sysobjects o INNER JOIN #tmp t ON o.id = t.id
WHERE (
o.base_schema_ver <> t.base_schema_ver
OR o.schema_ver <> t.schema_ver
)
AND o.type IN ('TR', 'P' ,'U' ,'V')
AND o.name NOT IN ( SELECT oi.name
FROM sysobjects oi INNER JOIN #tmp ti ON oi.id = ti.id
WHERE oi.name <> ti.name /*COLLATE*/
AND oi.type IN ('TR', 'P' ,'U' ,'V'))
UNION
--Changed (actually dropped and recreated [but not renamed])
SELECT 'changed' AS ChangeType, t.name, 'dropped' AS extra_info, 2 AS Priority
FROM #tmp t
WHERE t.name IN ( SELECT ti.name /*COLLATE*/ FROM #tmp ti
WHERE NOT EXISTS (SELECT * FROM sysobjects oi
WHERE oi.id = ti.id))
AND t.name IN ( SELECT oi.name /*COLLATE*/ FROM sysobjects oi
WHERE NOT EXISTS (SELECT * FROM #tmp ti
WHERE oi.id = ti.id)
AND oi.type IN ('TR', 'P' ,'U' ,'V'))
UNION
--Deleted
SELECT 'deleted' AS ChangeType, t.name, '' AS extra_info, 0 AS Priority
FROM #tmp t
WHERE NOT EXISTS (SELECT * FROM sysobjects o
WHERE o.id = t.id)
AND t.name NOT IN ( SELECT oi.name /*COLLATE*/ FROM sysobjects oi
WHERE NOT EXISTS (SELECT * FROM #tmp ti
WHERE oi.id = ti.id)
AND oi.type IN ('TR', 'P' ,'U' ,'V'))
UNION
--Added
SELECT 'added' AS ChangeType, o.name /*COLLATE*/, '' AS extra_info, 4 AS Priority
FROM sysobjects o
WHERE NOT EXISTS (SELECT * FROM #tmp t
WHERE o.id = t.id)
AND o.type IN ('TR', 'P' ,'U' ,'V')
AND o.name NOT IN ( SELECT ti.name /*COLLATE*/ FROM #tmp ti
WHERE NOT EXISTS (SELECT * FROM sysobjects oi
WHERE oi.id = ti.id))
ORDER BY Priority ASC
Примечание: если вы используете нестандартную сортировку в любой из ваших баз данных, вам нужно будет заменить /* COLLATE */ с вашей базой данных сопоставления. т.е. COLLATE Latin1_General_CI_AI
Я написал это приложение некоторое время назад, http://sqlschemasourcectrl.codeplex.com/ который будет сканировать ваши базы данных MSFT SQL так часто, как вы хотите, и автоматически выгружать ваши объекты (таблицы, представления, процедуры, функции, настройки SQL) в SVN. Работает как шарм. Я использую его с Unfuddle (что позволяет мне получать уведомления о регистрации)
После перехода на платформу x64 у нас возникла необходимость в версии нашей базы данных SQL, и наша старая версия порвала с миграцией. Мы написали приложение на C#, которое использовало SQLDMO для отображения всех объектов SQL в папке:
корень
Название сервера
DatabaseName
Объекты схемы
Триггеры базы данных *
.ddltrigger.sql
функции..function.sql
Безопасность
Роли
Роли приложений.approle.sql
Роли базы данных.role.sql
Schemas*
.schema.sql
пользователей.user.sql
Место хранения
Полнотекстовые каталоги *
.fulltext.sql
Хранимые процедуры..proc.sql
Синонимы *
.synonym.sql
таблицы..table.sql
Ограничения...chkconst.sql
...defconst.sql
Индексы... index.sql
Ключи...fkey.sql
...pkey.sql
...ukey.sql
Триггеры... trigger.sql
Типы
Определяемые пользователем типы данных..uddt.sql
Коллекции XML-схем *
..xmlschema.sql
Просмотры..view.sql
Индексы... index.sql
Триггеры... trigger.sqlЗатем приложение сравнивает вновь написанную версию с версией, хранящейся в SVN, и при наличии различий оно обновляет SVN. Мы определили, что запуск процесса один раз в ночь был достаточным, поскольку мы не вносили столько изменений в SQL. Это позволяет нам отслеживать изменения всех объектов, которые нас интересуют, а также позволяет нам перестраивать нашу полную схему в случае серьезной проблемы.
Мы не храним схему базы данных, мы храним изменения в базе данных. Что мы делаем, так это сохраняем изменения схемы, чтобы мы создали сценарий изменений для любой версии базы данных и применили его к базам данных наших клиентов. Я написал приложение для работы с базами данных, которое распространяется вместе с нашим основным приложением, которое может читать этот сценарий и знать, какие обновления необходимо применить. Он также имеет достаточно смартов для обновления представлений и хранимых процедур по мере необходимости.
Я согласен с ответом ESV, и именно по этой причине я некоторое время назад начал небольшой проект, чтобы помочь поддерживать обновления базы данных в очень простом файле, который затем мог бы содержать длинный исходный код. Это позволяет легко обновлять разработчикам, а также UAT и Production. Инструмент работает на Sql Server и MySql.
Некоторые особенности проекта:
- Позволяет изменения схемы
- Позволяет популяцию дерева значений
- Позволяет отдельные вставки тестовых данных, например. UAT
- Позволяет вариант для отката (не автоматизирован)
- Поддерживает поддержку сервера SQL и Mysql
- Имеет возможность импортировать вашу существующую базу данных в систему управления версиями с помощью одной простой команды (только SQL Server... все еще работает на MySQL)
Код размещен на Google Code. Пожалуйста, проверьте код Google для получения дополнительной информации
Это очень старый вопрос, однако многие пытаются решить его даже сейчас. Все, что им нужно сделать, это исследовать проекты баз данных Visual Studio. Без этого любая разработка базы данных выглядит очень слабой. От организации кода до развертывания и управления версиями все упрощается.
Типичное решение - при необходимости выгрузить базу данных и сделать резервную копию этих файлов.
В зависимости от вашей платформы разработки могут быть доступны плагины с открытым исходным кодом. Раскрутка собственного кода для этого обычно довольно тривиальна.
Примечание: вы можете сделать резервную копию дампа базы данных вместо того, чтобы поместить его в систему контроля версий. Файлы могут очень быстро работать при управлении версиями, что может привести к замедлению работы всей системы контроля версий (сейчас я вспоминаю ужасную историю CVS).
Мы только начали использовать Team Foundation Server. Если ваша база данных среднего размера, то Visual Studio имеет несколько хороших интеграций проектов со встроенным сравнением, сравнением данных, инструментами рефакторинга базы данных, инфраструктурой тестирования базы данных и даже инструментами генерации данных.
Но эта модель не очень хорошо подходит для больших или сторонних баз данных (которые шифруют объекты). Итак, что мы сделали, так это сохранили только наши индивидуальные объекты. Visual Studio / Team Foundation server очень хорошо работает для этого.
Я также использую версию в базе данных, хранимой через семейство процедур расширенных свойств базы данных. В моем приложении есть сценарии для каждого шага версии (т. Е. Перейти с 1.1 на 1.2). При развертывании он просматривает текущую версию и затем запускает сценарии один за другим, пока не достигнет последней версии приложения. Не существует сценария с прямой "финальной" версией, даже развертывание на чистой БД выполняет развертывание через серию шагов обновления.
Теперь я хотел бы добавить, что два дня назад я видел презентацию в кампусе MS о новом и готовящемся выпуске VS DB. Презентация была сосредоточена именно на этой теме, и меня выкинуло из воды. Вы должны обязательно это проверить, новые возможности сосредоточены на сохранении определения схемы в сценариях T-SQL (CREATE), дельта-движке времени выполнения для сравнения схемы развертывания с определенной схемой и выполнения дельта-изменений и интеграции с интеграцией исходного кода, вплоть до и в том числе MSBUILD непрерывной интеграции для автоматических сборок. Перетаскивание будет содержать новый тип файлов, файлы.dbschema, которые можно перенести на сайт развертывания, а инструмент командной строки может выполнить фактические "дельты" и запустить развертывание. У меня есть запись в блоге на эту тему со ссылками на загрузки VSDE, вы должны проверить их: http://rusanu.com/2009/05/15/version-control-and-your-database/
Некоторое время назад я нашел базовый модуль VB, который использовал объекты DMO и VSS, чтобы вывести весь сценарий БД из VSS. Я превратил его в скрипт VB и разместил здесь. Вы могли бы легко принимать вызовы VSS и использовать материал DMO для генерации всех сценариев, а затем вызывать SVN из того же пакетного файла, который вызывает сценарий VB Script для их регистрации?
Дэйв Дж
По моему опыту, решение имеет два аспекта:
Вам необходимо обработать изменения в базе данных разработки, которые были сделаны несколькими разработчиками во время разработки.
Вы должны обрабатывать обновления баз на сайтах клиентов.
Для того, чтобы справиться с № 1, вам понадобится мощный инструмент сравнения / слияния баз данных. Лучший инструмент должен иметь возможность выполнять автоматическое объединение в максимально возможной степени, позволяя вам разрешать необработанные конфликты вручную.
Идеальный инструмент должен обрабатывать операции слияния с использованием трехстороннего алгоритма слияния, который учитывает изменения, внесенные в базу данных THEIRS и базу данных MINE, относительно базы данных BASE.
Я написал коммерческий инструмент, который обеспечивает ручную поддержку слияния для баз данных SQLite, и в настоящее время я добавляю поддержку трехстороннего алгоритма слияния для SQLite. Проверьте это на http://www.sqlitecompare.com/
Для обработки #2 вам понадобится инфраструктура обновления на месте.
Основная идея заключается в разработке инфраструктуры автоматического обновления, которая знает, как обновить существующую схему SQL до более новой схемы SQL, и может создать путь обновления для каждой существующей установки БД.
Прочтите мою статью на эту тему в http://www.codeproject.com/KB/database/sqlite_upgrade.aspx чтобы получить общее представление о том, о чем я говорю.
Удачи
Лирон Леви
Проверьте DBGhost http://www.innovartis.co.uk/. Я использую в автоматическом режиме в течение 2 лет, и это прекрасно работает. Это позволяет нашим сборкам БД происходить так же, как происходит сборка на Java или C, за исключением базы данных. Если вы понимаете, о чем я.
Я бы предложил использовать инструменты сравнения для импровизации системы контроля версий для вашей базы данных. Хорошей альтернативой являются xSQL Schema Compare и xSQL Data Compare.
Теперь, если ваша цель состоит в том, чтобы иметь только схему базы данных под управлением версиями, вы можете просто использовать xSQL Schema Compare для генерации моментальных снимков схемы xSQL и добавления этих файлов в свой контроль версий. Затем, чтобы восстановить или обновить до определенной версии, просто сравните текущую версию базы данных со снимком для целевой версии.
Увы, если вы хотите, чтобы данные также находились под контролем версий, вы можете использовать xSQL Data Compare для генерации сценариев изменений для вашей базы данных и добавления файлов.sql в свой контроль версий. Затем вы можете выполнить эти скрипты, чтобы вернуться / обновить до любой версии, которую вы хотите. Помните, что для "возврата" вам необходимо сгенерировать сценарии изменений, которые при выполнении сделают Версию 3 такой же, как Версия 2, а для функции "обновления" вам необходимо сгенерировать сценарии изменений, которые делают обратное.
Наконец, с некоторыми базовыми навыками пакетного программирования вы можете автоматизировать весь процесс, используя версии командной строки xSQL Schema Compare и xSQL Data Compare.
Отказ от ответственности: я связан с xSQL.
Альтернативой контролю версий вашей базы данных является использование базы данных с контролем версий, которых сейчас существует несколько.
https://www.dolthub.com/blog/2021-09-17-database-version-control/
Эти продукты не применяют контроль версий поверх базы данных другого типа — они представляют собой собственные механизмы баз данных, поддерживающие операции контроля версий. Поэтому вам нужно перейти на них или начать использовать их в первую очередь.
Я пишу один из них, DoltDB, который сочетает в себе интерфейсы MySQL и Git. Проверьте это здесь: