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

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

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

29 ответов


Мартин Фаулер написал мою любимую статью на эту тему,http://martinfowler.com/articles/evodb.html. Я решил не помещать дампы схемы в систему управления версиями как alumb и другие предлагают, потому что я хочу простой способ обновить свою производственную базу данных.

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

Сценарии Обновления Базы Данных

обновление базы данных последовательности скрипты, содержащие DDL, необходимые для перемещения схемы из версии N в N+1. (Они входят в вашу систему управления версиями.) Таблица _version_history_, что-то вроде

create table VersionHistory (
    Version int primary key,
    UpgradeStart datetime not null,
    UpgradeEnd datetime
    );

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

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

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

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

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


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

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

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


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

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

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

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

  • сторонний инструмент ApexSQL Source Control

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

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

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

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


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


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

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

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


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


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

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

делает идеальное решение для управления версиями DB и делает синхронизацию DB легким.


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

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

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


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

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

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


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

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


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


все просто.

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

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

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

  4. когда приложение выпущено в производство, вы вернетесь к 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


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

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

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


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


У нас была необходимость в версии нашей базы данных 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 db так часто, как вы хотите, и автоматически сбрасывать ваши объекты (таблицы, представления, процессы, функции, настройки sql) в SVN. Работает как заклинание. Я использую его с Unfuddle (что позволяет мне получать оповещения о возвраты)


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

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

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


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

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

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

сайт MS TFS


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

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

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

код размещен на Google code. Пожалуйста, проверьте код Google для некоторых более информация

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


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

Дэйв Дж


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

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


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


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

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

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

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

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

Я написал коммерческий инструмент, который обеспечивает ручную поддержку слияния для баз данных SQLite, и в настоящее время я добавляю поддержку алгоритма 3-way merge для 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 в системе управления версиями. Затем вы можете выполнить эти сценарии для возврата / обновления до любой версии, которую хотите. Имейте в виду, что для функциональности "revert" вам нужно создать сценарии изменений, которые при выполнении сделают версию 3 такой же, как Версия 2 и для функциональности "обновление", вам нужно создать сценарии изменения, которые делают обратное.

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

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