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

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

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

Ответов (25)

Решение

Мартин Фаулер написал мою любимую статью на эту тему 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. Скрипт для восстановления (и, при необходимости, доработки) резервной копии на рабочей станции разработчика. Каждый разработчик запускает этот сценарий после каждого обновления производственной БД.

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

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

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

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

Это просто.

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

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

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

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

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

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

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

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

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

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

Если вам нужно сохранить все данные, я рекомендую сделать резервную копию базы данных и использовать продукты Redgate ( http://www.red-gate.com/ ) для сравнения. Они не из дешевых, но стоят каждого пенни.

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

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

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

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

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

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

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

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

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

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

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

Главный свод базы данных TFS. блог

Сайт MS TFS

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

\ Functions
\ Security
\ Security \ Roles
\ Security \ Schemas
\ Security \ Users
\ Хранимые процедуры
\ Таблицы

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

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

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

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

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

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

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

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

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

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

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

                Корень
                    Название сервера
                       DatabaseName
                          Объекты схемы
                             Триггеры базы данных *
                                .ddltrigger.sql
                             Функции
                                ..function.sql
                             Безопасность
                                Роли
                                   Роли приложений
                                      .approle.sql
                                   Роли базы данных
                                      .role.sql
                                Схемы *
                                   .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. Это позволяет нам отслеживать изменения всех объектов, которые нам небезразличны, а также позволяет нам перестроить нашу полную схему в случае серьезной проблемы.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Централизованная система контроля версий - стандартная система, в которой пользователи проверяют / регистрируют до / после работы с файлами, а файлы хранятся на одном центральном сервере.

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