My<cod/>.net
Управление версиями SQL база данных сервера
Я хочу, чтобы мои базы данных были под контролем версий. Есть ли у кого-нибудь какие-нибудь советы или Рекомендуемые статьи, чтобы я начал работу?
Я всегда буду хотеть иметь там хотя бы некоторые данные (как упоминает alumb: типы пользователей и администраторы). Мне также часто требуется большая коллекция сгенерированных тестовых данных для измерения производительности.
Мартин Фаулер написал мою любимую статью на эту тему, 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
);
получает новую запись каждый раз, когда запускается сценарий обновления, соответствующий новой версии.
Это гарантирует, что легко увидеть, какая версия схемы базы данных существует, и что сценарии обновления базы данных выполняются только один раз. Опять же, это не дампы баз данных. Скорее всего, каждый сценарий представляет собой изменения , необходимые для перехода от одной версии к другой. Это сценарий, который вы применяете к своей производственной базе данных для "upgrade" it.
Sandbox Разработчик Синхронизации
- Сценарий для резервного копирования, очистки и сжатия рабочей базы данных. Выполните это после каждого обновления до производственного DB.
- Скрипт для восстановления (и настройки, если это необходимо) резервной копии на рабочей станции разработчика. Каждый разработчик запускает этот сценарий после каждого обновления до production DB.
Предостережение: мои автоматические тесты работают против правильной схемы, но пустой базы данных, поэтому этот совет не будет идеально соответствовать вашим потребностям.
Продукт Red Gate SQL Compare не только позволяет выполнять сравнения на уровне объектов и генерировать сценарии изменений, но также позволяет экспортировать объекты базы данных в иерархию папок, организованную по типу объекта, с одним [objectname].sql сценарий создания каждого объекта в этих каталогах. Иерархия типов объектов выглядит следующим образом:
\Functions
\Security
\Security\Roles
\Security\Schemas
\Security\Users
\Stored процедуры
\Tables
Если вы сбрасываете свои сценарии в один и тот же корневой каталог после внесения изменений, вы можете использовать это для обновления вашего РЕПО SVN и сохранения истории выполнения каждого объекта по отдельности.
Это одна из "hard problems" окружающих разработок. Насколько мне известно, идеальных решений не существует.
Если вам нужно хранить только структуру базы данных, а не данные, вы можете экспортировать базу данных в виде запросов SQL. (в Enterprise Manager: щелкните правой кнопкой мыши на database - > Generate SQL script. Я рекомендую установить "create one file per object" на вкладке Параметры) Затем вы можете зафиксировать эти текстовые файлы в svn и использовать функции diff и ведения журнала svn.
У меня это связано с пакетным скриптом, который берет пару параметров и настраивает базу данных. Я также добавил некоторые дополнительные запросы, которые вводят данные по умолчанию, такие как типы пользователей и пользователь 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 Source Control, который использует технологию SQL Compare для связи вашей базы данных с репозиторием TFS или SVN. Этот инструмент интегрируется в SSMS и позволяет работать так же, как обычно, за исключением того, что теперь он позволяет фиксировать объекты.
Для подхода, основанного на миграции (более подходящего для автоматизированных развертываний), мы предлагаем SQL Change Automation (ранее называвшуюся ReadyRoll), которая создает и управляет набором инкрементных сценариев как проектом Visual Studio.
В системе управления версиями SQL можно указать статические таблицы данных. Они хранятся в системе управления версиями в виде инструкций INSERT.
Если вы говорите о тестовых данных, мы рекомендуем вам либо создать тестовые данные с помощью инструмента или с помощью сценария post-deployment, который вы определяете,либо просто восстановить производственную резервную копию в среде разработки.
Вы можете посмотреть на Liquibase (http://www.liquibase.org/). Даже если вы не используете сам инструмент, он довольно хорошо справляется с концепциями управления изменениями баз данных или рефакторинга.
+1 для всех, кто рекомендовал инструменты RedGate, с дополнительной рекомендацией и предостережением.
SqlCompare также имеет прилично документированный API: так что вы можете, например, написать консольное приложение, которое синхронизирует вашу папку скриптов с исходным кодом с базой данных интеграционного тестирования CI при проверке, так что когда кто-то проверяет изменение схемы из своей папки скриптов, оно автоматически развертывается вместе с соответствующим изменением кода приложения. Это помогает сократить разрыв с разработчиками, которые забывают о распространении изменений в своей локальной БД до общей разработки DB (около половины из нас, я думаю :) ).
Предостережение состоит в том, что с помощью скриптового решения или иным образом инструменты RedGate достаточно гладки, чтобы легко забыть о реальности SQL, лежащей в основе абстракции. Если вы переименуете все столбцы в таблице, SqlCompare не сможет сопоставить старые столбцы с новыми столбцами и удалит все данные в таблице. Он будет генерировать предупреждения, но я видел, как люди щелкают мимо этого. Здесь есть общий момент, который стоит отметить, я думаю, что вы можете автоматизировать только DB версионирование и обновление до сих пор - абстракции очень дырявые.
Мы используем DBGhost для управления нашей базой данных SQL. Затем вы помещаете свои сценарии для создания новой базы данных в систему управления версиями, и она либо создает новую базу данных, либо обновляет любую существующую базу данных до схемы в системе управления версиями. Таким образом, вам не нужно беспокоиться о создании сценариев изменений (хотя вы все еще можете это сделать, если, например, вы хотите изменить тип данных столбца и вам нужно преобразовать данные).
Это хороший подход для сохранения сценариев баз данных в системе управления версиями с помощью сценариев изменений, чтобы вы могли обновить любую имеющуюся базу данных. Кроме того, вы можете сохранить схемы для разных версий, чтобы создать полную базу данных без необходимости применять все сценарии изменений. Обработка скриптов должна быть автоматизирована, чтобы вам не приходилось выполнять ручную работу.
Я думаю, что важно иметь отдельную базу данных для каждого разработчика и не использовать общую базу данных. Таким образом, разработчики могут создавать тестовые случаи и этапы разработки независимо от других разработчиков.
Инструмент автоматизации должен иметь средства для обработки метаданных базы данных, которые сообщают, какие базы данных находятся в каком состоянии разработки и какие таблицы содержат данные, контролируемые версиями, и так далее.
Вы не упомянули никаких конкретных сведений о вашей целевой среде или ограничениях, поэтому это может быть не совсем применимо... но если вы ищете способ эффективно отслеживать эволюционирующую схему DB и не возражаете против идеи использования Ruby, то миграция ActiveRecord-это как раз то, что вам нужно.
Миграции программно определяют преобразования базы данных с использованием Ruby DSL; каждое преобразование может быть применено или (как правило) откатано, что позволяет перейти к другой версии схемы DB в любой заданный момент времени. Файл, определяющий эти преобразования, можно проверить в системе управления версиями, как и любой другой фрагмент исходного кода.
Поскольку миграции являются частью ActiveRecord, они обычно находят применение в приложениях с полным стеком Rails; однако вы можете использовать ActiveRecord независимо от Rails с минимальными усилиями. Смотрите здесь более подробное описание использования миграций AR за пределами Rails.
Каждая база данных должна находиться под контролем исходного кода. Чего не хватает, так это инструмента для автоматического скриптирования всех объектов базы данных-и "configuration data"-в файл, который затем может быть добавлен в любую систему управления версиями. Если вы используете сервер SQL, то мое решение здесь : http://dbsourcetools.codeplex.com/ . Повеселись. - Натан.
Все очень просто.
Когда базовый проект будет готов, вы должны создать полный сценарий базы данных. Этот сценарий передается в SVN. Это первая версия.
После этого все разработчики создают сценарии изменений (ALTER..., новые таблицы, sprocs и т. д.).
Если вам нужна текущая версия, то вы должны выполнить все новые сценарии изменений.
Когда приложение будет выпущено в производство, вы вернетесь к 1 (но тогда это будет последовательная версия, конечно).
Nant поможет вам выполнить эти сценарии изменений. :)
И запомните. Все прекрасно работает, когда есть дисциплина. Каждый раз, когда происходит изменение базы данных, то соответствующие функции в коде также включаются.
Если у вас есть небольшая база данных, и вы хотите верифицировать все это, этот пакетный скрипт может помочь. Он отсоединяет, сжимает и проверяет файл базы данных MSSQL _28 в Subversion.
Если вы в основном хотите верифицировать свою схему и просто иметь небольшой объем справочных данных, вы можете использовать _29 миграций для обработки этого. Преимущество заключается в том, что вы можете легко мигрировать вверх или вниз до любой конкретной версии.
Поскольку наше приложение должно работать с несколькими RDBMSs, мы храним наше определение схемы в системе управления версиями, используя нейтральный к базе данных формат крутящего момента (XML). Мы также контролируем версию справочных данных для нашей базы данных в формате XML следующим образом (где "Relationship" - одна из справочных таблиц):
<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
Я написал Это приложение некоторое время назад, http://sqlschemasourcectrl.codeplex.com/ которое будет сканировать ваши MSFT SQL db так часто, как вы хотите, и автоматически сбрасывать ваши объекты (таблицы, представления, процессы, функции, настройки sql) в SVN. Работает как заклинание. Я использую его с Unfuddle (что позволяет мне получать оповещения о чеках)
Мы не храним схему базы данных, мы храним изменения в базе данных. Мы храним изменения схемы таким образом, чтобы создать сценарий изменений для любой версии базы данных и применить его к базам данных наших клиентов. Я написал приложение database utility, которое распространяется вместе с нашим основным приложением, которое может читать этот скрипт и знать, какие обновления необходимо применить. Он также имеет достаточно интеллектуальных возможностей для обновления представлений и хранимых процедур по мере необходимости.
У нас была необходимость в версии нашей базы данных 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. Это позволяет нам отслеживать изменения во всех объектах, которые нас интересуют, а также позволяет нам перестроить нашу полную схему в случае серьезной проблемы.
Я согласен с ESV ответом и именно по этой причине я начал небольшой проект некоторое время назад, чтобы помочь поддерживать обновления базы данных в очень простом файле, который затем может быть сохранен в виде длинного стороннего исходного кода. Он позволяет легко обновлять данные для разработчиков, а также для UAT и производства. Инструмент работает на сервере but Sql и MySql.
Некоторые особенности проекта:
- Позволяет вносить изменения в схему
- Разрешает заполнение дерева значений
- Позволяет отдельных тестовых данных для вставки, например. UAT
- Позволяет вариант для отката (не автоматизированный)
- Поддерживает поддержку для SQL сервера и Mysql
- Имеет возможность импортировать существующую базу данных в систему управления версиями с помощью одной простой команды (sql server only ... все еще работаем над mysql)
Код размещен на google code. Пожалуйста, проверьте Google code для получения дополнительной информации
http://code.google.com/p/databaseversioncontrol/
Типичным решением является сброс базы данных по мере необходимости и резервное копирование этих файлов.
В зависимости от вашей платформы разработки, могут быть доступны плагины с открытым исходным кодом. Прокатки свой собственный код, чтобы сделать это, как правило, достаточно банален.
Примечание: Вы можете создать резервную копию дампа базы данных, а не помещать его в систему управления версиями. Файлы могут получить огромную скорость в системе управления версиями и привести к тому, что вся ваша система управления версиями станет медленной (я вспоминаю ужасную историю CVS в данный момент).
Мы только начали использовать Team Foundation Server. Если ваша база данных среднего размера, то visual studio имеет несколько хороших интеграций проектов со встроенными средствами сравнения, сравнения данных, рефакторинга баз данных, платформы тестирования баз данных и даже средства генерации данных.
Но эта модель не очень хорошо подходит для очень больших или сторонних баз данных (которые шифруют объекты). Итак, то, что мы сделали, - это хранить только наши настроенные объекты. Visual Studio / Team foundation server работает очень хорошо для этого.
TFS главный арх базы данных. блог
Некоторое время назад я нашел модуль VB bas, который использовал объекты DMO и VSS, чтобы получить весь сценарий db от и до VSS. Я превратил его в сценарий VB и разместил здесь . Вы можете легко взять вызов VSS и использовать материал DMO для создания всех сценариев, а затем вызвать SVN из того же пакетного файла, который вызывает VBScript, чтобы проверить их?
Дэйв Джей
Я также использую версию в базе данных, хранящейся через семейство процедур database extended properties. Мое приложение имеет скрипты для каждого шага версии (т. е. перейти от 1.1 к 1.2). При развертывании он просматривает текущую версию и затем запускает сценарии один за другим, пока не достигнет последней версии приложения. Нет никакого сценария, который имеет прямую версию 'final', даже развертывание на чистом DB делает развертывание через серию шагов обновления.
Теперь я хотел бы добавить, что два дня назад я видел презентацию на кампусе MS о новом и предстоящем выпуске VS DB. Презентация была сосредоточена именно на этой теме, и я был выброшен из воды. Вы определенно должны проверить это, новые средства сосредоточены на сохранении определения схемы в скриптах T-SQL (CREATEs), движке runtime delta engine для сравнения схемы deployment с определенной схемой и выполнения дельты ALTERs и интеграции с интеграцией исходного кода, вплоть до непрерывной интеграции MSBUILD для автоматизированных отбрасываний сборки. Падение будет содержать новый тип файла, файлы .dbschema, которые могут быть перенесены на сайт deployment, а средство командной строки может выполнить фактический 'deltas' и запустить deployment. У меня есть запись в блоге на эту тему со ссылками на VSDE загрузок, вы должны проверить их: http://rusanu.com/2009/05/15/version-control-and-your-database/