Существует множество отработанных систем контроля версий за исходными кодами программ (sourcesafe, subversion, cvs, starteam, PVCS и т.д.), а существуют ли аналоги для разработчиков баз данных, и вообще идеология контроля версий. При попытке применить систему контроля версий для программ выявлены проблемы. Попытка заключалась в создании библиотеки скриптов всех объектов базы данных (Table, View, SP, UDF, Defaults, т.д.) и хранение версий каждого объекта в starteam аналогично програмным кодам. Выявлены следующие проблемы:

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

2. Не отражаются взаимосвязи объектов. Например есть скрипт таблицы и SP. Поменялась таблица и поменялась SP. Хранятся скрипты начального и конечного состояния таблицы и SP. Но для правильного перехода от одной версии к другой сначала должна меняться таблица, а потом SP, иначе обновить версию не получится. Зависимости могут принимать достаточно сложный характер...

Есть и другие проблемы....

В конечном итоге:
1) Есть стандартная промышленная база данных которая не может быть отключена и которая должна работать 24 часа в сутки без проблем
2) Есть набор приложений которые работают с базой данных: относительно небольшой, исчисляется десяками приложений, относительно небольшого размера (не более миллиона строк каждое)
3) Есть несколько программистов которые работают над разработкой и могут иметь потребности в изменнеии существующих объектов в базе данных, причём возможны ситуации когда несколько программистов имеют потребность в изменении одного и того же объекта
4) Есть нормальный цикл разработки: разработка-тестирование-внедрение
5) Можно допустить что при разработке не производится существенных манипуляций с самими данными (я понимаю, что если в процессе перехода от версии к версии уничтожается таблица, то никакими скриптами ворзвратить базу данных в исходное состояние невозможно)

Итого как организовать правильно процесс разработки и контроля версий изменений в базе данных?

На старой работе был такой подход(попробую вспомнить все нюансы...)
Львиная часть логики была в SP.
Идеология была такова:
Если ты создал таблицу и всунул в ЦВС - это НАВСЕГДА! Если хочешь изменить что-либо - изволь писать скрипт альтер. Но пересоздавать НЕЛЬЗЯ. Даже если таблица не суть критична и пуста.
Как настраивали ЦВС - не скажу. Не участвовал.
Но было так, что любое изменение повышало айдишку билда на единичку. То есть таблицу изменили - 12567. Абсолютно не связанную с ней процедуру - 12658.
В базе была спец. табличка для хранения версий и созданных объектов.
Кроме того было написано небольшое приложение на сях, которое бежало по всему ЦВСу и строило txt файлик - просто список ВСЕХ скриптов.
При необходимости, скрипт передвигался в нём ручками выше/ниже. При повторной пробежке - добавляло только ВНОВЬ ПОЯВИВШИЕСЯ СКРИПТЫ.
То есть порядок старых сохранялся.
И эта же софтинка запускала сборку скриптов на боевых серваках.
Причём, если в базе последнее обновление - 12567, то начинало со скрипта, айди модификации которого больше 12657 и далее. порядок брался из txt файла.

А главное - НИЧЕГО И НИКОГДА НЕ УДАЛЯТЬ! Только дописывать скрипты, которые имеющееся правят.
Ну и часто писали скрипты так, чтоб он проверял стоит ли ему делать то, что он собирается делать(в некоторых тонких местах).

для InterBase есть замечательная программка IBExpert. Там есть возможность сравнить две базы и построить скрип перехода от одной к другой

а также существует компонент VCL comparer, на котором это сравнение и построено

База данных - MS SQL Server

А принципиально важным является откат версии до предыдущей?
Или только для случаев, когда неудачно прошёл патч до следующей версии?

Используем subversion - каждое изменение (revision) затрагивает сразу несколько файлов, то есть такой проблемы там просто не может возникнуть

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




А что такого даёт subversion относительно баз данных, чего не дают другие системы контроля версий? Я немного знаком с subversion и признаться ничего существенно отличного в этом направлении там не нашёл. Кроме того база данных это не "файлы", и отличие от програмного кода тут очень и очень существенное. Пример: у вас есть 2 модуля программы каждый из которых был изменён. Теперь надо откатить изменения. Есть разница в том чтобы откатить изменение модуля А первым, или модуля Б первым? Нет конечно! На момент компилляции всё равно будут все модули уже в откатанном состоянии. А теперь база данных, изменения: А - в "мастер" таблицу добавлены все необходимые значения и Б - добавлен внешний ключ, так чтобы одна из существующих таблиц стала "detail" с каскадными операциями. Как будем откатывать? Если сначала удалить добавленные записи из мастер таблицы а потом внешний ключ, то это грозит потерями живых данных, а наоборот нет. Или например чтобы поменять в MS SQL Server кластерный индекс с поля по которому сделан первичный ключ на другое, надо последовательно произвести: удаление текущего первичного ключа, создание кластерного индекса по другому полю, пересоздание первичного ключа как был только без "кластерности" причём только в этом порядке и ни в каком другом.

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

Хм... вроде такого не делали никогда. Создавался набор скриптов, устанавливалась последовательность их запуска. Потом делали копию боевой базы с помощью дамп/лоад и на ней запускали скрипты. Если прошло на ура - то на боевой. Если вдруг чего-то падало - то ручками правили. То есть не откатывали, а закатывали до победного . Но это очччень редко, при явно забитом .. на эту последовательность действий.

А если всё-таки нужно почему-то откатить - тогда руками скрипт отката. И проверить его на тестовой опять-таки. Но лучшим выходом считаю контрольный накат на копию базы.

А вам не кажется, что гораздо поще остановить базу на к примеру 5 минут, сделать бэкап, попытаться запустить скрипт обновления, если успешно, то включить новую базу, если ошибка, то востановить из бэкапа. Не знаю может я ошибаюсь, но я плохо себе представляю как можно откатить базу к примеру на 2 версии назад по ее структуре, ведь новая структура зачем-то делалась и явно были созданы поля для хранения новых данных, налажены новые связи, куда в случаи отката девать эти новые данные?

PS:
В не возможность остановки базы на 5 минут не поверю, т.к. в любом случаи вы вносите изменения в базу не в момент когда к ней подключены клиенты, т.к. не известно с какими данными в данный момент работает клиент и как ваши изменения воспримут его работу.

Хм... бэкап базы размером приближающейся к терробайту занимает минимум 3-4 часа... На 3 часа остановить базу данных можно только с субботы на воскресенье в полночь, в огстальное время на 4 часа остановить нельзя, а даже если сделать дубликат до за несколько часов базы будут существенно различаться по содержимым данным...

PS. Это корпоративная база данных на пол тысячи персонала в нескольких офисах расположенных в разных штатах, на ~30 млн. клиентов... в общем не самая маленькая что в жизни встречаются... Бэкап и даже простое копирование - достаточно геморройно, так как пары лишних террабайтов для хранения дополнительных бэкапов и копий баз данных не всегда можно легко найти...




Изменения вносятся без отключения базы данных естественно... Теоретически конечно возможно возникновение мусора, но для предотвращения этого естественно не выключается вся база данных, а только останавливаются клиентские приложения которые могут быть вовлечены в процесс. Зачем отключать 100 сервисов и клиентских приложений, если изменения затронут только 1 приложение и тех кто с ним работает? Конечно бывают более серьёзные update требующие остановки сервиса... Ну тогда составляются специальные графики проведения работ, за неделю рассылаются предупреждения всем партнёрам и заказчикам, и производятся такие работы в ночь с сууботы на воскресенья полной бригадой - программисты+системщики... В общем пару раз такая морока была, к счастью последние 3 месяца необходимости останавливать базу данных не возникало...

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

Vit
Насчет отличия базы от файлов - всё не так страшно: можно изготовить утилиту для преобразования структуры базы в файлы и обратно. Порядок изменений и отката - это действительно проблема, и должна она решаться логикой того же ПО преобразования. От системы контроля версий здесь нужно, чтобы все связанные изменения были в одной её транзакции (собственно, поэтому и svn)

Ну... в принципе... больше ничего и не требуется. По идее.
Ночью в выходные слили дамп. С ТЕКУЩЕЙ СТРУКТУРОЙ ДАННЫХ.
Запустили отдельно на резервном сервере. И попробовали накатить. Не прошло - заново из дампа освежили, подправили скрипты - и опять. А тогда уже на боевую.
Понятно что места не бывает много.... Но, согласен с Алексом. Для дампа и тестовой базы с текущей копией боевой место лучше иметь...
Ибо без такого это немного откатывается к шаманству и приходится больше уповать на мастерство, интуицию и умение работать в состоянии аврала программеров и системщиков. Мну так думать.
У нас было несколько девелоперских и тестовых баз. так вот на тестовые запрещено было делать что-либо лапками. Только скрипты из поставки накатывать. Копия всегда бралась с боевых серверов. И за день таких лоадов/накатов могло быть до 2-3. В процесе разработки. Но к моменту установки на боевые - влюбой мог отдать пятку на растерзание, что всё проскочит как ведро в колодец.