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

Question

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

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

Answer 1

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

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

Answer 2

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

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

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

Answer 3

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

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

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

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

Answer 4

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

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

• Распределенная система контроля версий - система, в которой репозиторий клонируется, и каждый клон фактически является полной резервной копией репозитория, поэтому в случае сбоя любого сервера любой клонированный репозиторий можно использовать для восстановления После выбора правильной системы для ваших нужд, вам нужно настроить репозиторий, который является ядром каждой системы контроля версий Все это объясняется в следующей статье: http://solutioncenter.apexsql.com/sql-server-source-control-part-i-understanding-source-control-basics/

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

• SQL Server Management Studio через поставщика MSSCCI,

• Инструменты данных Visual Studio и SQL Server

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

Answer 5

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

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

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

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

Answer 6

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

Answer 7

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

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

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

Answer 8

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

Answer 9

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

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

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

Answer 10

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

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

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