Управление версиями базы данных SQL Server

08-06-2019
|

Вопрос

Я хочу, чтобы мои базы данных находились под контролем версий.Есть ли у кого-нибудь какие-нибудь советы или рекомендуемые статьи, которые помогли бы мне начать?

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

Решение

Мартин Фаулер написал мою любимую статью на эту тему, 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
    );

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

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

Синхронизация песочницы разработчика

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

Одно предостережение:Мои автоматизированные тесты выполняются с корректной по схеме, но пустой базой данных, поэтому этот совет не совсем соответствует вашим потребностям.

Другие советы

Продукт Red Gate SQL Compare не только позволяет вам проводить сравнения на уровне объектов и генерировать на их основе сценарии изменений, но также позволяет вам экспортировать объекты вашей базы данных в иерархию папок, организованную по типу объекта, с одним сценарием создания [objectname].sql для каждого объекта в этих каталогах.Иерархия типов объектов выглядит следующим образом:

\Функции
\Безопасность
\Безопасность\Роли
\Безопасность\Схемы
\Безопасность\Пользователи
\Хранимые процедуры
\Таблицы

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

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

Если вам нужно сохранить только структуру базы данных, а не данные, вы можете экспортировать базу данных в виде SQL-запросов.(в Enterprise Manager:Щелкните правой кнопкой мыши на базе данных -> Сгенерировать SQL-скрипт.Я рекомендую установить "создавать по одному файлу для каждого объекта" на вкладке параметры) Затем вы можете передать эти текстовые файлы в svn и использовать функции svn diff и ведения журнала.

У меня это связано с пакетным скриптом, который принимает пару параметров и настраивает базу данных.Я также добавил несколько дополнительных запросов, которые вводят данные по умолчанию, такие как типы пользователей и пользователь admin.(Если вы хотите получить больше информации об этом, опубликуйте что-нибудь, и я смогу разместить скрипт где-нибудь в доступном месте)

Если вам также необходимо сохранить все данные, я рекомендую создать резервную копию базы данных и использовать 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 для управления версиями

Здесь, в Red Gate, мы предлагаем инструмент, Управление исходным кодом SQL, который использует технологию SQL Compare для связывания вашей базы данных с репозиторием TFS или SVN.Этот инструмент интегрируется в SSMS и позволяет вам работать как обычно, за исключением того, что теперь он позволяет вам фиксировать объекты.

Для подхода, основанного на миграции (больше подходящего для автоматизированных развертываний), мы предлагаем Автоматизация изменений SQL (ранее назывался ReadyRoll), который создает набор инкрементных сценариев и управляет ими как проектом Visual Studio.

В системе управления версиями SQL можно указать статические таблицы данных.Они хранятся в системе управления версиями в виде инструкций INSERT.

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

Возможно, вы захотите взглянуть на Liquibase (http://www.liquibase.org/).Даже если вы не используете сам инструмент, он довольно хорошо справляется с концепциями управления изменениями базы данных или рефакторинга.

+ 1 для всех, кто рекомендовал RedGate tools, с дополнительной рекомендацией и оговоркой.

SQLCompare также имеет прилично документированный API:таким образом, вы можете, например, написать консольное приложение, которое синхронизирует вашу папку сценариев с исходным кодом с базой данных тестирования интеграции CI при проверке, так что, когда кто-то проверяет изменение схемы из своей папки сценариев, оно автоматически развертывается вместе с соответствующим изменением кода приложения.Это помогает сократить разрыв с разработчиками, которые забывают распространять изменения в своей локальной базе данных вплоть до общей базы данных разработки (я думаю, около половины из нас :) ).

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

Мы используем DBGhost для управления нашей базой данных SQL.Затем вы помещаете свои скрипты для создания новой базы данных в систему управления версиями, и она либо создает новую базу данных, либо обновляет любую существующую базу данных до схемы в системе управления версиями.Таким образом, вам не нужно беспокоиться о создании сценариев изменения (хотя вы все еще можете это сделать, если, например, вы хотите изменить тип данных столбца и вам нужно преобразовать данные).

В VS 2010 используйте проект базы данных.

Создайте сценарий для вашей базы данных
Внести изменения в скрипты или непосредственно на ваш сервер БД
Синхронизация с использованием данных > Сравнение схемы

Создает идеальное решение для управления версиями БД и упрощает синхронизацию БД.

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

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

Инструмент автоматизации должен иметь средства для обработки метаданных базы данных, которые сообщают, какие базы данных находятся в каком состоянии разработки, какие таблицы содержат данные с контролем версий и так далее.

Вы также могли бы взглянуть на решение для миграции.Они позволяют вам указать схему вашей базы данных в коде C # и изменять версию вашей базы данных вверх и вниз с помощью MSBuild.

В настоящее время я использую DbUp, и это работает хорошо.

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

Миграции программно определяют преобразования базы данных с использованием Ruby DSL;каждое преобразование может быть применено или (обычно) откатано, что позволяет вам перейти к другой версии вашей схемы БД в любой данный момент времени.Файл, определяющий эти преобразования, может быть проверен в системе управления версиями, как и любой другой фрагмент исходного кода.

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

Каждая база данных должна находиться под контролем исходного кода.Чего не хватает, так это инструмента для автоматического преобразования всех объектов базы данных - и "конфигурационных данных" - в файл, который затем можно добавить в любую систему управления версиями.Если вы используете SQL Server, то мое решение находится здесь : http://dbsourcetools.codeplex.com/ .Получайте удовольствие.- Натан.

Все очень просто.

Когда базовый проект будет готов, вы должны создать полный сценарий базы данных.Этот скрипт передан в SVN.Это первая версия.
После этого все разработчики создают сценарии изменений (ALTER ..., новые таблицы, sprocs и т.д.).
Когда вам нужна текущая версия, вы должны выполнить все новые сценарии изменения.
Когда приложение будет запущено в производство, вы вернетесь к 1 (но тогда, конечно, это будет последовательная версия).

Nant поможет вам выполнить эти сценарии изменений.:)

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

Если у вас небольшая база данных, и вы хотите обновить версию всего объекта, этот пакетный скрипт могло бы помочь.Он отсоединяет, сжимает и проверяет MDF-файл базы данных MSSQL в Subversion.

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

Чтобы сделать дамп в систему управления исходным кодом немного быстрее, вы можете увидеть, какие объекты изменились с прошлого раза, используя информацию о версии в 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

Поскольку наше приложение должно работать с несколькими СУБД, мы сохраняем определение нашей схемы в системе управления версиями, используя нейтральный к базе данных Крутящий момент формат (XML).Мы также контролируем версии справочных данных для нашей базы данных в формате XML следующим образом (где "Связь" является одной из справочных таблиц):

  <Relationship RelationshipID="1" InternalName="Manager"/>
  <Relationship RelationshipID="2" InternalName="Delegate"/>
  etc.

Затем мы используем самодельные инструменты для создания сценариев обновления схемы и справочных данных, которые необходимы для перехода с версии X базы данных на версию X + 1.

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

У нас возникла необходимость обновить нашу базу данных SQL после того, как мы перешли на платформу x64, и наша старая версия вышла из строя при переносе.Мы написали приложение на C #, которое использовало SQLDMO для отображения всех объектов SQL в папку:

                Root
                    ServerName
                       DatabaseName
                          Schema Objects
                             Database Triggers*
                                .ddltrigger.sql
                             Functions
                                ..function.sql
                             Security
                                Roles
                                   Application Roles
                                      .approle.sql
                                   Database Roles
                                      .role.sql
                                Schemas*
                                   .schema.sql
                                Users
                                   .user.sql
                             Storage
                                Full Text Catalogs*
                                   .fulltext.sql
                             Stored Procedures
                                ..proc.sql
                             Synonyms*
                                .synonym.sql
                             Tables
                                ..table.sql
                                Constraints
                                   ...chkconst.sql
                                   ...defconst.sql
                                Indexes
                                   ...index.sql
                                Keys
                                   ...fkey.sql
                                   ...pkey.sql
                                   ...ukey.sql
                                Triggers
                                   ...trigger.sql
                             Types
                                User-defined Data Types
                                   ..uddt.sql
                                XML Schema Collections*
                                   ..xmlschema.sql
                             Views
                                ..view.sql
                                Indexes
                                   ...index.sql
                                Triggers
                                   ...trigger.sql

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

Я написал это приложение некоторое время назад, http://sqlschemasourcectrl.codeplex.com/ который будет сканировать вашу базу данных MSFT SQL так часто, как вы захотите, и автоматически сбрасывать ваши объекты (таблицы, представления, процедуры, функции, настройки sql) в SVN.Работает как заклинание.Я использую его с Unfuddle (что позволяет мне получать оповещения о проверках).

Типичным решением является сброс базы данных по мере необходимости и резервное копирование этих файлов.

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

Примечание:Возможно, вы захотите создать резервную копию дампа базы данных вместо того, чтобы помещать его в систему управления версиями.Файлы могут стать очень быстрыми в системе управления версиями и привести к замедлению работы всей вашей системы управления версиями (в данный момент я вспоминаю ужасную историю CVS).

Мы только начали использовать Team Foundation Server.Если ваша база данных среднего размера, то в Visual Studio есть несколько приятных интеграций проекта со встроенными инструментами сравнения, data compare, рефакторинга базы данных, платформой тестирования базы данных и даже инструментами генерации данных.

Но эта модель не очень хорошо подходит для очень больших или сторонних баз данных (которые шифруют объекты).Итак, что мы сделали, так это сохранили только наши настроенные объекты.Visual Studio / Team Foundation server очень хорошо подходит для этого.

Главный архив базы данных TFS.Блог

Сайт MS TFS

Я согласен с ответом ESV, и именно по этой причине некоторое время назад я запустил небольшой проект, помогающий поддерживать обновления базы данных в очень простом файле, который затем можно было бы поддерживать длинным исходным кодом.Это позволяет легко обновлять как разработчикам, так и UAT и Production.Инструмент работает только на Sql Server и MySQL.

Некоторые особенности проекта:

Позволяет изменять схему
Разрешает заполнение дерева значений
Позволяет вставлять отдельные тестовые данные, например.UAT
Разрешает опцию отката (не автоматизированного)
Поддерживает поддержку SQL server и Mysql
Имеет возможность импортировать вашу существующую базу данных в систему управления версиями с помощью одной простой команды (только для sql server ...все еще работаю над mysql)

Код размещен в Google Code.Пожалуйста, ознакомьтесь с Google Code для получения дополнительной информации

http://code.google.com/p/databaseversioncontrol/

Некоторое время назад я нашел модуль VB bas, который использовал объекты DMO и VSS для вывода всей базы данных из скрипта в VSS.Я превратил это в VB-скрипт и опубликовал его здесь.Вы могли бы легко удалить вызовы VSS и использовать материал DMO для генерации всех сценариев, а затем вызвать SVN из того же пакетного файла, который вызывает VBScript, чтобы проверить их?

Дэйв Джей

Я также использую версию в базе данных, хранящуюся через семейство процедур database extended properties.В моем приложении есть сценарии для каждого шага версии (т.е.перейти с 1.1 на 1.2).При развертывании он просматривает текущую версию, а затем запускает сценарии один за другим, пока не дойдет до последней версии приложения.Не существует скрипта, который имел бы прямую "окончательную" версию, даже развертывание на чистой базе данных выполняет развертывание с помощью серии шагов обновления.

Теперь я хотел бы добавить, что два дня назад я видел презентацию в кампусе MS о новом и готовящемся выпуске VS DB.Презентация была посвящена именно этой теме, и я был ошеломлен.Вам обязательно стоит это проверить, новые средства ориентированы на сохранение определения схемы в скриптах T-SQL (CREATEs), на дельта-движок среды выполнения для сравнения схемы развертывания с определенной схемой и выполнения дельта-изменений и интеграции с интеграцией исходного кода, вплоть до непрерывной интеграции MSBUILD для автоматического удаления сборки.Удаление будет содержать файлы нового типа .dbschema, которые можно перенести на сайт развертывания, а инструмент командной строки может выполнить фактические "дельты" и запустить развертывание.У меня есть запись в блоге на эту тему со ссылками на загрузки VSDE, вы должны проверить их: http://rusanu.com/2009/05/15/version-control-and-your-database/

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

По моему опыту, решение двоякое:

Вам необходимо обработать изменения в базе данных разработки, которые вносятся несколькими разработчиками во время разработки.
Вам необходимо выполнить обновление базы данных на сайтах клиентов.

Чтобы справиться с # 1, вам понадобится мощный инструмент для разделения / слияния баз данных.Лучший инструмент должен быть способен выполнять автоматическое слияние в максимально возможной степени, позволяя вам разрешать необработанные конфликты вручную.

Идеальный инструмент должен обрабатывать операции слияния с использованием трехходового алгоритма слияния, который учитывает изменения, внесенные в ИХ базу данных и базу данных MINE, относительно БАЗОВОЙ базы данных.

Я написал коммерческий инструмент, который обеспечивает поддержку ручного слияния для баз данных SQLite, и в настоящее время я добавляю поддержку 3-стороннего алгоритма слияния для 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 и Сравнение данных xSQL.

Теперь, если ваша цель состоит в том, чтобы иметь только схему базы данных под контролем версий, вы можете просто использовать xSQL Schema Compare для создания моментальных снимков схемы в xSQL и добавления этих файлов в ваш контроль версий.Затем, чтобы вернуться или обновить до определенной версии, просто сравните текущую версию базы данных со снимком для целевой версии.

Увы, если вы хотите, чтобы данные также находились под контролем версий, вы можете использовать xSQL Data Compare для создания сценариев изменения для вашей базы данных и добавления файлов .sql в ваш контроль версий.Затем вы могли бы выполнить эти скрипты для возврата / обновления до любой версии, которую вы хотите.Имейте в виду, что для функции "отменить" вам необходимо сгенерировать сценарии изменений, которые при выполнении сделают версию 3 такой же, как версия 2, а для функции "обновить" вам нужно сгенерировать сценарии изменений, которые делают обратное.

Наконец, обладая некоторыми базовыми навыками пакетного программирования, вы можете автоматизировать весь процесс, используя версии командной строки xSQL Schema Compare и xSQL Data Compare

Отказ от ответственности:Я связан с xSQL.

Лицензировано под: CC-BY-SA с атрибуция

Не связан с StackOverflow