Методология управления версиями SQL

Question

Есть несколько вопросов о SO об управлении версиями для SQL и множестве ресурсов в Интернете, но я не могу найти то, что полностью охватывает то, что я пытаюсь сделать.

Во-первых, я говорю о методологии здесь. Я знаком с различными приложениями для управления версиями, и я знаком с такими инструментами, как SQL Compare от Red Gate и т. Д., И я знаю, как написать приложение, чтобы автоматически проверять ситуацию в исходной системе управления и из нее. Если есть инструмент, который был бы особенно полезен при создании целой новой методологии или который имел бы полезную и необычную функциональность, тогда отлично, но для задач, упомянутых выше, я уже установлен.

Требования, которые я пытаюсь встретиться является: данные

• схемы базы данных и просмотровых таблицы версионируются
• DML скриптов для исправления данных для больших таблиц версионируются
• Сервера, может быть повышена с версии N до версии N + X, где X не всегда может быть 1
• Код не дублируется в системе управления версиями - например, если я добавлю столбец в таблицу, я не хочу иметь чтобы изменения были как в сценарии создания, так и в скрипте alter IPT
• Система должна поддерживать несколько клиентов, которые находятся в различных версиях для приложения (пытаясь получить их все до в течение 1 или 2-х выпусков, но еще не там)

Некоторые организации держать дополнительные сценарии изменения в их управлении версиями и для получения от версии N до N + 3 вам придется запускать скрипты для N-> N + 1, затем N + 1-> N + 2, затем N + 2-> N + 3. Некоторые из этих сценариев могут повторяться (например, добавляется столбец, но затем он изменяется для изменения типа данных). Мы стараемся избегать такой повторяемости, поскольку некоторые из клиентских БД могут быть очень большими, поэтому эти изменения могут занять больше времени, чем это необходимо.

Некоторые организации просто сохраняют полный скрипт построения базы данных на каждом уровне версии, а затем используют такой инструмент, как SQL Compare, чтобы довести базу данных до одной из этих версий. Проблема здесь в том, что смешивание сценариев DML может быть проблемой. Представьте сценарий, когда я добавляю столбец, используйте DML-скрипт для заполнения указанного столбца, а затем в более поздней версии это имя столбца изменяется.

Возможно, существует гибридное решение? Может быть, я просто прошу слишком много? Однако любые идеи или предложения были бы весьма полезными.

Если модераторы считают, что это было бы более уместно как вики сообщества, пожалуйста, дайте мне знать.

Спасибо!

Answer 1

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

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

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

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

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

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

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 и т.д ...

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

Answer 2

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

В tsf нет.в особенности avialbe как

• Datacompare
• Schemacompare
• версия управления

о системе управления версиями базы данных: 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

Answer 3

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

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

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

Answer 4

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

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

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

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

Answer 5

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

Вот описание подхода SQL Ревизора: How to get your database under version control

Answer 6

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