Я хочу получить свои базы данных под управлением версии. У кого-нибудь есть какие-либо советы или рекомендуемые статьи, чтобы начать меня?
Я всегда хочу иметь по крайней мере некоторые данные там (как 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
);
получает новую запись каждый раз, когда выполняется обновление script, которое соответствует новой версии.
Это гарантирует, что будет легко увидеть, какая версия схемы базы данных существует, а сценарии обновления базы данных выполняются только один раз. Опять же, это дампы базы данных не. Скорее, каждый script представляет изменения, необходимые для перехода от одной версии к другой. Это script, который вы применяете к своей производственной базе данных для "обновления".
Предостережение. Мои автоматические тесты выполняются с корректной, но пустой базой данных, поэтому этот совет не будет соответствовать вашим потребностям.
Продукт Red SQL SQL Compare не только позволяет выполнять сопоставления на уровне объекта, но и создавать сценарии изменений, но также позволяет экспортировать объекты базы данных в иерархию папок, организованную по типу объекта, с одним [имя_объекта].sql создание script для каждого объекта в этих каталогах. Иерархия типа объекта выглядит следующим образом:
\ Функции
\
безопасности
\ Security\Роли
\ Security\Schemas
\ Security\Users
\ Хранимые процедуры
\ Таблицы
Если вы сбрасываете свои скрипты в один и тот же корневой каталог после внесения изменений, вы можете использовать это, чтобы обновить репозиторий SVN и сохранить историю выполнения каждого объекта отдельно.
Это одна из трудных проблем, связанных с развитием. Насколько я знаю, нет идеальных решений.
Если вам нужно сохранить структуру базы данных, а не данные, вы можете экспортировать базу данных в виде SQL-запросов. (в Enterprise Manager: щелкните правой кнопкой мыши по базе данных → Generate SQL script. Я рекомендую установить "создать один файл на один объект" на вкладке параметров). Затем вы можете передать эти текстовые файлы в svn и использовать svn diff и logging функции.
Я связал это вместе с Batch script, который принимает пару параметров и настраивает базу данных. Я также добавил некоторые дополнительные запросы, которые вводят данные по умолчанию, такие как типы пользователей и пользователь admin. (Если вы хотите получить дополнительную информацию об этом, опубликуйте что-нибудь, и я смогу разместить script где-нибудь доступным)
Если вам нужно сохранить все данные, я рекомендую сохранить резервную копию базы данных и использовать Redgate (http://www.red-gate.com/) для сравнения. Они не дешевы, но они стоят каждого пенни.
Сначала вы должны выбрать подходящую для вас систему управления версиями:
Централизованная система управления версиями - стандартная система, в которой пользователи проверяют/проверяют до/после работы с файлами, а файлы хранятся на одном центральном сервере
Система управления распределенной версией - система, в которой клонируется репозиторий, и каждый клон на самом деле является полной резервной копией репозитория, поэтому, если какой-либо сервер выходит из строя, тогда любой клонированный репозиторий может быть использован для его восстановления После выбора правильной системы для ваших нужд вам необходимо настроить репозиторий, который является основой каждой системы управления версиями Все это объясняется в следующей статье: http://solutioncenter.apexsql.com/sql-server-source-control-part-i-understanding-source-control-basics/
После настройки репозитория, а в случае центральной системы управления версиями - рабочей папки, вы можете прочитать this article. Он показывает, как настроить источник управления в среде разработки, используя:
SQL Server Management Studio через поставщика MSSCCI,
Инструменты данных Visual Studio и SQL Server
Здесь, в Red Gate, мы предлагаем инструмент SQL Source Control, который использует технологию SQL Compare для связи вашей базы данных с репозиторием TFS или SVN. Этот инструмент интегрируется в SSMS и позволяет вам работать как обычно, за исключением того, что теперь он позволяет фиксировать объекты.
Для подхода на основе миграции (более подходящего для автоматических развертываний) мы предлагаем SQL Change Automation (ранее называлась ReadyRoll), которая создает и управляет набором инкрементных сценариев как проект Visual Studio.
В SQL Source Control можно указывать статические таблицы данных. Они хранятся в системе контроля версий как операторы INSERT.
Если вы говорите о тестовых данных, мы рекомендуем вам либо создавать тестовые данные с помощью инструмента, либо с помощью заданного вами сценария после развертывания, либо просто восстанавливать производственную резервную копию в среду разработки.
Вы можете посмотреть на Liquibase (http://www.liquibase.org/). Даже если вы не используете сам инструмент, он отлично справляется с концепциями управления изменениями базы данных или рефакторингом.
+1 для всех, кто рекомендовал инструменты RedGate, с дополнительной рекомендацией и предостережением.
SqlCompare также имеет документально подтвержденный API: поэтому вы можете, например, написать консольное приложение, которое синхронизирует вашу папку с контролируемыми версиями сценариев с базой данных тестирования интеграции CI при проверке, так что когда кто-то проверяет изменения в схеме из их папку сценариев автоматически развертывается вместе с соответствующим изменением кода приложения. Это помогает сократить разрыв с разработчиками, которые забывают о распространении изменений в их локальном db до общей БД разработки (примерно половина из нас, я думаю:)).
Предостережение заключается в том, что с помощью скриптового решения или иным образом инструменты RedGate достаточно гладкие, что легко забыть о реалиях SQL, лежащих в основе абстракции. Если вы переименуете все столбцы в таблице, SqlCompare не сможет сопоставить старые столбцы с новыми столбцами и выведет все данные в таблице. Он будет генерировать предупреждения, но я видел, как люди щелкали мимо этого. Там, как мне кажется, стоит обратить внимание на то, что вы можете только автоматизировать обновление БД и обновление до сих пор - абстракции очень непроницаемы.
Мы используем DBGhost для управления нашей базой данных SQL. Затем вы ставите свои скрипты для создания новой базы данных в вашем управлении версиями, и она либо построит новую базу данных, либо обновит любую существующую базу данных до схемы в управлении версиями. Таким образом, вам не нужно беспокоиться о создании сценариев изменений (хотя вы все равно можете это сделать, если, например, вы хотите изменить тип данных столбца и вам нужно преобразовать данные).
С VS 2010 используйте проект базы данных.
Создает идеальное решение для управления версиями БД и делает синхронизацию БД легкой.
Это хороший подход для сохранения сценариев базы данных в управлении версиями с помощью сценариев изменений, чтобы вы могли обновлять любую имеющуюся у вас базу данных. Также вы можете сохранить схемы для разных версий, чтобы создать полную базу данных без необходимости применять все сценарии изменений. Обработка сценариев должна быть автоматизирована, так что вам не нужно выполнять ручную работу.
Я думаю, что важно иметь отдельную базу данных для каждого разработчика и не использовать общую базу данных. Таким образом, разработчики могут создавать тестовые примеры и фазы разработки независимо от других разработчиков.
Средство автоматизации должно иметь средства для обработки метаданных базы данных, в которых указывается, какие базы данных находятся в каком состоянии разработки и в каких таблицах содержатся контролируемые версией данные и т.д.
Вы не указали каких-либо особенностей вашей целевой среды или ограничений, поэтому это может быть не совсем применимо... но если вы ищете способ эффективно отслеживать эволюционирующую схему БД и не неблагоприятны для идея использования Ruby, миграции ActiveRecord находится прямо вверх по вашей аллее.
Миграции программно определяют преобразования базы данных с использованием Ruby DSL; каждое преобразование может быть применено или (обычно) откат назад, что позволяет вам перейти к другой версии вашей схемы БД в любой момент времени. Файл, определяющий эти преобразования, можно проверить в управлении версиями, как и любой другой фрагмент исходного кода.
Поскольку миграции являются частью ActiveRecord, они обычно находят применение в приложениях с полным стеком Rails; однако вы можете использовать ActiveRecord независимо от Rails с минимальными усилиями. См. здесь для более подробного описания использования AR-миграций вне Rails.
Вы также можете посмотреть на решение по миграции. Это позволяет вам указать схему вашей базы данных в коде С# и прокрутить версию базы данных вверх и вниз, используя MSBuild.
В настоящее время я использую DbUp, и он работал хорошо.
Каждая база данных должна находиться под контролем исходного кода. Отсутствует инструмент автоматического script всех объектов базы данных - и "данные конфигурации" - в файл, который затем может быть добавлен в любую систему управления версиями. Если вы используете SQL Server, то мое решение находится здесь: http://dbsourcetools.codeplex.com/. Повеселись. - Натан.
Это просто.
Когда базовый проект готов, вы должны создать полную базу данных script. Этот script присваивается SVN. Это первая версия.
После этого все разработчики создают скрипты изменений (ALTER..., новые таблицы, sprocs и т.д.).
Если вам нужна текущая версия, вы должны выполнить все новые скрипты изменений.
Когда приложение будет выпущено к выпуску, вы вернетесь к 1 (но тогда это будет последовательная версия, конечно).
Nant поможет вам выполнить эти сценарии изменений.:)
И помни. Все работает нормально, когда есть дисциплина. Каждый раз, когда происходит смена базы данных, также выполняются соответствующие функции в коде.
Если у вас есть небольшая база данных, и вы хотите выполнить ее версию, эта серия script может помочь. Он отделяет, сжимает и проверяет файл MDF базы данных MSSQL в Subversion.
Если вы в основном хотите обновить свою схему и просто иметь небольшое количество справочных данных, вы можете использовать SubSonic Migrations, чтобы справиться с этим. Преимущество в том, что вы можете легко переносить вверх или вниз до любой конкретной версии.
Поскольку наше приложение должно работать на нескольких РСУБД, мы сохраняем наше определение схемы в контроле версий с использованием нейтрального по базе данных Torque формата ( 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-скрипты только для тех, кого вы интересуете, и поместить их в исходный элемент управления по вашему выбору. p >
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
Мы не храним схему базы данных, мы сохраняем изменения в базе данных. Что мы делаем, так это сохранение изменений схемы, чтобы мы построили изменение script для любой версии базы данных и применили ее к базам данных наших клиентов. Я написал приложение для базы данных, которое распространяется с нашим основным приложением, которое может читать это script и знать, какие обновления необходимо применять. Он также имеет достаточно умений для обновления представлений и хранимых процедур по мере необходимости.
Нам потребовалась версия нашей базы данных SQL после перехода на платформу x64, и наша старая версия сломалась с переносом. Мы написали приложение С#, которое использовало 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 так часто, как вы хотите, и автоматически сбрасывать свои объекты (таблицы, представления, procs, функции, настройки sql) в SVN. Работает как шарм. Я использую его с Unfuddle (что позволяет мне получать предупреждения при проверках)
Типичным решением является сброс базы данных по мере необходимости и резервное копирование этих файлов.
В зависимости от вашей платформы разработки могут быть доступны плагины с открытым исходным кодом. Роллинг собственного кода для этого обычно довольно тривиален.
Примечание. Возможно, вы захотите сделать резервную копию дампа базы данных вместо того, чтобы поместить его в управление версиями. Файлы могут получить очень быстро в управлении версиями и заставить всю систему управления версиями стать медленными (я вспоминаю историю ужасов CVS на данный момент).
Мы только начали использовать Team Foundation Server. Если ваша база данных имеет средний размер, тогда визуальная студия обладает отличной интеграцией проектов со встроенным сравнением, сравнением данных, инструментами рефакторинга базы данных, базой тестирования базы данных и даже инструментами для создания данных.
Но эта модель не очень подходит для очень больших или сторонних баз данных (которые шифруют объекты). Итак, что мы сделали, это хранить только наши настроенные объекты. Сервер Foundation Visual Studio/Team работает очень хорошо для этого.
Я согласен с ответом ESV, и по этой причине я немного начал проект, чтобы помочь поддерживать обновления баз в очень простом файле, который затем может быть сохранен в исходном коде с длинной стороны. Это позволяет легко обновлять разработчиков, а также UAT и Production. Инструмент работает, но Sql Server и MySql.
Некоторые функции проекта:
Код размещен в коде google. Пожалуйста, ознакомьтесь с кодом Google для получения дополнительной информации.
Некоторое время назад я обнаружил базовый модуль 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 Database. Без этого любая разработка базы данных выглядит очень слабой. От организации кода до развертывания до версии, это упрощает все.
В моем опыте решение двоякое:
Вам необходимо обработать изменения в базе данных разработки, которые выполняются несколькими разработчиками во время разработки.
Вам нужно обрабатывать обновления баз данных на сайтах клиентов.
Чтобы обрабатывать # 1, вам понадобится сильный инструмент разграничения/слияния базы данных. Лучший инструмент должен иметь возможность выполнять автоматическое слияние как можно больше, позволяя вам разрешать необработанные конфликты вручную.
Идеальный инструмент должен обрабатывать операции слияния с помощью трехмерного алгоритма слияния, который учитывает изменения, внесенные в базу данных THEIRS и базу данных MINE, относительно базы данных BASE.
Я написал коммерческий инструмент, который обеспечивает ручную поддержку слияния для баз данных SQLite, и в настоящее время я добавляю поддержку алгоритма слияния 3-way для 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 в ваш контроль версий. Затем вы можете выполнить эти сценарии, чтобы вернуться/обновить любую желаемую версию. Имейте в виду, что для функции "вернуть" вам необходимо сгенерировать сценарии изменений, которые при выполнении сделают Version 3 таким же, как Version 2 и для функции "update", вам нужно сгенерировать скрипты изменений, которые делают наоборот.
Наконец, с некоторыми основными навыками пакетного программирования вы можете автоматизировать весь процесс, используя версии командной строки xSQL Schema Compare и xSQL Data Compare
Отказ от ответственности: я связан с xSQL.