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

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

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

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

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

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

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

Если вы вносите свои сценарии в тот же корневой каталог после внесения изменений, вы можете использовать это для обновления репозитория 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-основы /

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

• 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.

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

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

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

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

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

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

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

1. Сценарий вашей базы данных
2. Внесите изменения в сценарии или непосредственно на вашем сервере БД
3. Синхронизация с использованием Data> Schema Compare

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

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

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

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

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

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

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

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

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

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

Это просто.

1. Когда базовый проект готов, вы должны создать полный скрипт базы данных. Этот скрипт передан в SVN. Это первая версия.

2. После этого все разработчики создают сценарии изменений (ALTER ..., новые таблицы, sprocs и т. Д.).

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

4. Когда приложение выпущено в производство, вы возвращаетесь к 1 (но, конечно, это будет последовательная версия).

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

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

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

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

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

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

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

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

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

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

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

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

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

База данных TFS начальник арх. блог

Сайт MS TFS

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

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

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

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

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

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

Дэйв Дж

Я также использую версию в базе данных, хранимой через семейство процедур расширенных свойств базы данных. В моем приложении есть сценарии для каждого шага версии (т. Е. Перейти с 1.1 на 1.2). При развертывании он просматривает текущую версию и затем запускает сценарии один за другим, пока не достигнет последней версии приложения. Не существует сценария с прямой «финальной» версией, даже развертывание на чистой БД выполняет развертывание через серию шагов обновления.

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

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

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

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

2. Вы должны обрабатывать обновления баз на сайтах клиентов.

Для того, чтобы справиться с № 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.