Методология контроля версий SQL

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

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

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

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

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

Примеры из недавнего проекта:

001.sql:

if object_id(N'dbo.Registrations') is null 
begin
    create table dbo.Registrations
    (
        [Id]                    uniqueidentifier not null,
        [SourceA]               nvarchar(50)     null,
        [SourceB]               nvarchar(50)     null,
        [Title]                 nvarchar(50)     not null,
        [Occupation]            nvarchar(50)     not null,
        [EmailAddress]          nvarchar(100)    not null,
        [FirstName]             nvarchar(50)     not null,
        [LastName]              nvarchar(50)     not null,
        [ClinicName]            nvarchar(200)    not null,
        [ClinicAddress]         nvarchar(50)     not null,
        [ClinicCity]            nvarchar(50)     not null,
        [ClinicState]           nchar(2)         not null,
        [ClinicPostal]          nvarchar(10)     not null,
        [ClinicPhoneNumber]     nvarchar(10)     not null,
        [ClinicPhoneExtension]  nvarchar(10)     not null,
        [ClinicFaxNumber]       nvarchar(10)     not null,
        [NumberOfVets]          int              not null,  
        [IpAddress]             nvarchar(20)     not null,
        [MailOptIn]             bit              not null,
        [EmailOptIn]            bit              not null,
        [Created]               datetime         not null,
        [Modified]              datetime         not null,
        [Deleted]               datetime         null
    );
end

if not exists(select 1 from information_schema.table_constraints where constraint_name = 'pk_registrations')
    alter table dbo.Registrations add
        constraint pk_registrations primary key nonclustered (Id);

if not exists (select 1 from sysindexes where [name] = 'ix_registrations_created')
    create clustered index ix_registrations_created
        on dbo.Registrations(Created);

if not exists (select 1 from sysindexes where [name] = 'ix_registrations_email')
    create index ix_registrations_email
        on dbo.Registrations(EmailAddress);

if not exists (select 1 from sysindexes where [name] = 'ix_registrations_email')
    create index ix_registrations_name_and_clinic
        on dbo.Registrations (FirstName,
                              LastName,
                              ClinicName);

002.sql

/**********************************************************************
  The original schema allowed null for these columns, but we don't want
  that, so update existing nulls and change the columns to disallow 
  null values
 *********************************************************************/

update dbo.Registrations set SourceA = '' where SourceA is null;
update dbo.Registrations set SourceB = '' where SourceB is null;
alter table dbo.Registrations alter column SourceA nvarchar(50) not null;
alter table dbo.Registrations alter column SourceB nvarchar(50) not null;

/**********************************************************************
  The client wanted to modify the signup form to include a fax opt-in
 *********************************************************************/

if not exists 
(
    select 1 
      from information_schema.columns
     where table_schema = 'dbo'
       and table_name   = 'Registrations'
       and column_name  = 'FaxOptIn'
)
alter table dbo.Registrations 
    add FaxOptIn bit null 
        constraint df_registrations_faxoptin default 0;

003.sql, 004.sql и т. Д.

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

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

Самый многообещающий инструмент, о котором я читал о таких подгонках, - это Liquibase.
Вот некоторые из них. дополнительные ссылки:

• http://en.wikipedia.org/wiki/LiquiBase
• http://www.ibm.com/developerworks/java/library/j-ap08058/index.html

Да, вы многого просите, но все они действительно уместны! Здесь, в Red Gate, мы движемся к созданию полного решения для разработки баз данных с нашим расширением SSMS для управления исходным кодом SQL, и мы сталкиваемся с аналогичными проблемами.

http://www.red-gate.com/products/SQL_Source_Control/index.htm

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

Самым сложным требованием, для которого еще нет простого решения, является управление версиями и развертывание, которые вы очень четко описываете. Если вы вносите сложные изменения в схему и данные, может оказаться неизбежным создание вручную созданного сценария миграции для перехода между двумя соседними версиями, поскольку не все «намерения» всегда сохраняются вместе с более новой версией. Переименование столбцов - яркий тому пример. Решением может быть разработка системы, которая сохраняет намерение или, если это слишком сложно, позволяет пользователю предоставить пользовательский сценарий для выполнения сложного изменения. Какая-то структура управления версиями могла бы управлять ими и «волшебным образом» создавать сценарии развертывания из двух произвольных версий.

для такого рода проблем используйте Visual studio team system 2008 для контроля версий вашей базы данных sql.

В цф нет. функции avialbe like

• Datacompare
• Схема сравнения
• контроль версий

об управлении версиями базы данных: http://www.codinghorror.com/blog/2006/12/is-your-database-under-version-control.html для более подробной проверки: http://msdn.microsoft.com/en-us/library/ms364062(VS.80).aspx

Мы используем SQL Examiner для контроля версий схемы базы данных. Я также пробовал VS2010, но, на мой взгляд, подход VS слишком сложен для малых и средних проектов. С SQL Examiner я в основном работаю с SSMS и использую SQL Examiner для регистрации обновлений в SVN (также поддерживаются TFS и SourceSafe, но я никогда не пробовал).

Вот описание подхода SQL Examiner: Как поставить вашу базу данных под контроль версий

Попробуйте DBSourceTools. (http://dbsourcetools.codeplex.com)
Его открытый исходный код, специально разработанный для сценариев всю базу данных - таблицы, представления, процедуры на диск, а затем воссоздайте эту базу данных с помощью целевого объекта развертывания.
Вы можете создать сценарий для всех данных или просто указать, для каких таблиц следует сценарий данных.
Кроме того, вы можете заархивировать результаты для распространения.
Мы используем его для контроля версий баз данных и для тестирования исправлений обновлений для новых выпусков.
На внутреннем уровне он построен на основе SMO и, таким образом, поддерживает SQL 2000 , 2005 и 2008.
DBDiff интегрирован для сравнения схем.
Удачи, - Натан.