| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > СУБД, общие вопросы > Идеология контроля версий |
| Автор: Vit 15.2.2006, 16:38 |
| Существует множество отработанных систем контроля версий за исходными кодами программ (sourcesafe, subversion, cvs, starteam, PVCS и т.д.), а существуют ли аналоги для разработчиков баз данных, и вообще идеология контроля версий. При попытке применить систему контроля версий для программ выявлены проблемы. Попытка заключалась в создании библиотеки скриптов всех объектов базы данных (Table, View, SP, UDF, Defaults, т.д.) и хранение версий каждого объекта в starteam аналогично програмным кодам. Выявлены следующие проблемы: 1. Не отражаются механизмы изменения объектов с предыдущего состояния до конечного. Например имееется таблица, есть скрипт создания её старой версии, есть скрипт её создания в новой версии, но автоматически нет скрипта переделки таблицы из старой версии в новую и наоборот (для отката изменений), конечно можно для любой трансформации писать свой скрипт, но во первых его неудобно хранить в системе контроля версий, так как он формально не является скриптом объекта, а во вторых велики накладные расходы - на каждое изменение надо ещё писать дополнительно 2 скрипта как эти изменения сделать и отменить. 2. Не отражаются взаимосвязи объектов. Например есть скрипт таблицы и SP. Поменялась таблица и поменялась SP. Хранятся скрипты начального и конечного состояния таблицы и SP. Но для правильного перехода от одной версии к другой сначала должна меняться таблица, а потом SP, иначе обновить версию не получится. Зависимости могут принимать достаточно сложный характер... Есть и другие проблемы.... В конечном итоге: 1) Есть стандартная промышленная база данных которая не может быть отключена и которая должна работать 24 часа в сутки без проблем 2) Есть набор приложений которые работают с базой данных: относительно небольшой, исчисляется десяками приложений, относительно небольшого размера (не более миллиона строк каждое) 3) Есть несколько программистов которые работают над разработкой и могут иметь потребности в изменнеии существующих объектов в базе данных, причём возможны ситуации когда несколько программистов имеют потребность в изменении одного и того же объекта 4) Есть нормальный цикл разработки: разработка-тестирование-внедрение 5) Можно допустить что при разработке не производится существенных манипуляций с самими данными (я понимаю, что если в процессе перехода от версии к версии уничтожается таблица, то никакими скриптами ворзвратить базу данных в исходное состояние невозможно) Итого как организовать правильно процесс разработки и контроля версий изменений в базе данных? |
| Автор: chief39 15.2.2006, 21:10 |
| На старой работе был такой подход(попробую вспомнить все нюансы...) Львиная часть логики была в SP. Идеология была такова: Если ты создал таблицу и всунул в ЦВС - это НАВСЕГДА! Если хочешь изменить что-либо - изволь писать скрипт альтер. Но пересоздавать НЕЛЬЗЯ. Даже если таблица не суть критична и пуста. Как настраивали ЦВС - не скажу. Не участвовал. Но было так, что любое изменение повышало айдишку билда на единичку. То есть таблицу изменили - 12567. Абсолютно не связанную с ней процедуру - 12658. В базе была спец. табличка для хранения версий и созданных объектов. Кроме того было написано небольшое приложение на сях, которое бежало по всему ЦВСу и строило txt файлик - просто список ВСЕХ скриптов. При необходимости, скрипт передвигался в нём ручками выше/ниже. При повторной пробежке - добавляло только ВНОВЬ ПОЯВИВШИЕСЯ СКРИПТЫ. То есть порядок старых сохранялся. И эта же софтинка запускала сборку скриптов на боевых серваках. Причём, если в базе последнее обновление - 12567, то начинало со скрипта, айди модификации которого больше 12657 и далее. порядок брался из txt файла. А главное - НИЧЕГО И НИКОГДА НЕ УДАЛЯТЬ! Только дописывать скрипты, которые имеющееся правят. Ну и часто писали скрипты так, чтоб он проверял стоит ли ему делать то, что он собирается делать(в некоторых тонких местах). |
| Автор: DeadMan83 17.2.2006, 13:14 |
| для InterBase есть замечательная программка IBExpert. Там есть возможность сравнить две базы и построить скрип перехода от одной к другой |
| Автор: Bose 17.2.2006, 14:12 | ||
а также существует компонент http://www.clevercomponents.com/products/dbcvcl/dbcvcl.asp, на котором это сравнение и построено |
| Автор: Vit 17.2.2006, 16:25 |
| База данных - MS SQL Server |
| Автор: chief39 21.2.2006, 10:04 |
| А принципиально важным является откат версии до предыдущей? Или только для случаев, когда неудачно прошёл патч до следующей версии? |
| Автор: Dian 21.2.2006, 10:17 | ||
Используем subversion - каждое изменение (revision) затрагивает сразу несколько файлов, то есть такой проблемы там просто не может возникнуть |
| Автор: Vit 21.2.2006, 16:23 | ||||
Принципиально. Конечно только для неудачных случаев, но проблема в том, что база та "на ходу", поэтому если всё пошло "на перекосяк", то тратить время над ломанием головы как это откатить назад в общем-то нет, очень желательно иметь более или менее готовое решение на этот случай.
А что такого даёт subversion относительно баз данных, чего не дают другие системы контроля версий? Я немного знаком с subversion и признаться ничего существенно отличного в этом направлении там не нашёл. Кроме того база данных это не "файлы", и отличие от програмного кода тут очень и очень существенное. Пример: у вас есть 2 модуля программы каждый из которых был изменён. Теперь надо откатить изменения. Есть разница в том чтобы откатить изменение модуля А первым, или модуля Б первым? Нет конечно! На момент компилляции всё равно будут все модули уже в откатанном состоянии. А теперь база данных, изменения: А - в "мастер" таблицу добавлены все необходимые значения и Б - добавлен внешний ключ, так чтобы одна из существующих таблиц стала "detail" с каскадными операциями. Как будем откатывать? Если сначала удалить добавленные записи из мастер таблицы а потом внешний ключ, то это грозит потерями живых данных, а наоборот нет. Или например чтобы поменять в MS SQL Server кластерный индекс с поля по которому сделан первичный ключ на другое, надо последовательно произвести: удаление текущего первичного ключа, создание кластерного индекса по другому полю, пересоздание первичного ключа как был только без "кластерности" причём только в этом порядке и ни в каком другом. Главное отличие базы данных от программы в этом контексте, что вы никогда не можете работать с "мёртвой" базой данных, как с редактором кода, база данных всегда в работающем состоянии, любое изменние базы данных это не только то что вы изменили, это сразу же изменение и всех зависимых от данной ситуации объектов. Вы переименовываете поле в таблице и автоматически переименовываются поля в представлениях, перестают работать какие-то SP и триггеры, автоматически становятся другими скрипты на создание индексов и т.п. |
| Автор: chief39 21.2.2006, 17:19 | ||
Хм... вроде такого не делали никогда. Создавался набор скриптов, устанавливалась последовательность их запуска. Потом делали копию боевой базы с помощью дамп/лоад и на ней запускали скрипты. Если прошло на ура - то на боевой. Если вдруг чего-то падало - то ручками правили. То есть не откатывали, а закатывали до победного  . Но это очччень редко, при явно забитом .. на эту последовательность действий.А если всё-таки нужно почему-то откатить - тогда руками скрипт отката. И проверить его на тестовой опять-таки. Но лучшим выходом считаю контрольный накат на копию базы. |
| Автор: Alex 21.2.2006, 21:40 |
| А вам не кажется, что гораздо поще остановить базу на к примеру 5 минут, сделать бэкап, попытаться запустить скрипт обновления, если успешно, то включить новую базу, если ошибка, то востановить из бэкапа. Не знаю может я ошибаюсь, но я плохо себе представляю как можно откатить базу к примеру на 2 версии назад по ее структуре, ведь новая структура зачем-то делалась и явно были созданы поля для хранения новых данных, налажены новые связи, куда в случаи отката девать эти новые данные? PS: В не возможность остановки базы на 5 минут не поверю, т.к. в любом случаи вы вносите изменения в базу не в момент когда к ней подключены клиенты, т.к. не известно с какими данными в данный момент работает клиент и как ваши изменения воспримут его работу. |
| Автор: Vit 22.2.2006, 00:33 | ||
| Хм... бэкап базы размером приближающейся к терробайту занимает минимум 3-4 часа... На 3 часа остановить базу данных можно только с субботы на воскресенье в полночь, в огстальное время на 4 часа остановить нельзя, а даже если сделать дубликат до за несколько часов базы будут существенно различаться по содержимым данным... PS. Это корпоративная база данных на пол тысячи персонала в нескольких офисах расположенных в разных штатах, на ~30 млн. клиентов... в общем не самая маленькая что в жизни встречаются... Бэкап и даже простое копирование - достаточно геморройно, так как пары лишних террабайтов для хранения дополнительных бэкапов и копий баз данных не всегда можно легко найти...
Изменения вносятся без отключения базы данных естественно... Теоретически конечно возможно возникновение мусора, но для предотвращения этого естественно не выключается вся база данных, а только останавливаются клиентские приложения которые могут быть вовлечены в процесс. Зачем отключать 100 сервисов и клиентских приложений, если изменения затронут только 1 приложение и тех кто с ним работает? Конечно бывают более серьёзные update требующие остановки сервиса... Ну тогда составляются специальные графики проведения работ, за неделю рассылаются предупреждения всем партнёрам и заказчикам, и производятся такие работы в ночь с сууботы на воскресенья полной бригадой - программисты+системщики... В общем пару раз такая морока была, к счастью последние 3 месяца необходимости останавливать базу данных не возникало... |
| Автор: Alex 22.2.2006, 00:48 |
| Мда, задача не из простых, но по мне вносить изменения в базу без предварительного резервного копирования это пороховая бочка, которая однажды может рвануть. Или нужно все десконально отлаживать на тестовой базе |
| Автор: Dian 22.2.2006, 08:36 |
| Vit Насчет отличия базы от файлов - всё не так страшно: можно изготовить утилиту для преобразования структуры базы в файлы и обратно. Порядок изменений и отката - это действительно проблема, и должна она решаться логикой того же ПО преобразования. От системы контроля версий здесь нужно, чтобы все связанные изменения были в одной её транзакции (собственно, поэтому и svn) |
| Автор: chief39 22.2.2006, 11:12 | ||
Ну... в принципе... больше ничего и не требуется. По идее. Ночью в выходные слили дамп. С ТЕКУЩЕЙ СТРУКТУРОЙ ДАННЫХ. Запустили отдельно на резервном сервере. И попробовали накатить. Не прошло - заново из дампа освежили, подправили скрипты - и опять. А тогда уже на боевую. Понятно что места не бывает много.... Но, согласен с Алексом. Для дампа и тестовой базы с текущей копией боевой место лучше иметь... Ибо без такого это немного откатывается к шаманству и приходится больше уповать на мастерство, интуицию и умение работать в состоянии аврала программеров и системщиков. Мну так думать. У нас было несколько девелоперских и тестовых баз. так вот на тестовые запрещено было делать что-либо лапками. Только скрипты из поставки накатывать. Копия всегда бралась с боевых серверов. И за день таких лоадов/накатов могло быть до 2-3. В процесе разработки. Но к моменту установки на боевые - влюбой мог отдать пятку на растерзание, что всё проскочит как ведро в колодец. |
