Изменение структуры БД

← →
Unknown_user (2011-01-19 10:17) [0]

Вопрос скорее теоретический, чем практический.

Есть некая структура реляционной БД, есть клиентское приложение, которое умеет с ней работать. Пользователи накапливают данные в этой базе. Затем возникает необходимость поменять ее структуру. Добавляются новые таблицы, добавляются поля в существующие таблицы, добавляются внешние ключи и индексы. Клиентское приложение соответствующим образом модифицируется.

Вопрос.

Как перенести данные из предыдущих версий БД в актуальную версию, если учесть, что структура БД меняется часто. Например, как перейти от версии БД 1.0 к 1.5 или 1.3 к 1.5 (в первом случае структура БД менялась 6 раз, во втором 3 раза). Неужели нужно при каждом изменении схемы БД закладывать в клиента процедуры переноса данных и хранить их для каждого инкремента версии от 1.0 к 1.1, от 1.1 к 1.2 и т.д? Есть более рациональный способ?

← →
Ega23 © (2011-01-19 10:25) [1]

Патч-скрипт. Или система патч-скриптов.

← →
Медвежонок ХМЛ © (2011-01-19 10:47) [2]

Как перенести данные из предыдущих версий БД в актуальную версию

Зачем?
Меняй структуру рабочей БД и не надо ничего никуда переносить.

← →
ANB (2011-01-19 11:04) [3]

alter наше все

← →
Проходимец (2011-01-19 11:48) [4]

> структура БД меняется часто

Тогда самое правильное решение - уволить проектировщиков.

← →
KSergey © (2011-01-19 12:12) [5]

Как уже писали - необходимо делать систему патч-скриптов.
Все их делают, так что не надо думать, что вы отскочите по-простому :)

Желательно очень стараться, чтобы отдельные патч-скрипты были атомарны и по возможности независимы, это очень упростит жизнь саппортерам.

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

Если на примере. Если хотим точно и гарантированно устанавливать патчи последовательно, то каждый update-SQL-скрипт надо оформить, например, по такому шаблону:

SET @cur_patch_ver = 15 IF (SELECT MAX(installed_patch_num) FROM tbl_sql_patches) < (@cur_patch_ver-1) THEN BEGIN HALT("Сначала необхордимо установить патч с номером " + (@cur_patch_ver-1)) END BEGIN TRAN -- здесь тело собственно атомарного update-скрипта номер 15 ... ... IF @@ERRORS_COUNT > 0 THEN BEGIN ROLLBACK TRAN HALT("ERROR!") END -- сохраним признак установленности текущего патча INSERT INTO tbl_sql_patches (installed_patch_num) VALUES (@cur_patch_ver) COMMIT TRAN

Синтаксис условный, сорри, SQL-скрипты не пишу давно.

← →
KSergey © (2011-01-19 12:14) [6]

> Проходимец (19.01.11 11:48) [4]
> > структура БД меняется часто
> Тогда самое правильное решение - уволить проектировщиков.

Вообще-то структура БД, как правило, меняется от версии к версии продукта постоянно во всех проектах, где я участвовал.
Так что предлагаемое вами решение и его мотивы мне не понятны.

← →
Anatoly Podgoretsky © (2011-01-19 12:25) [7]

> Unknown_user (19.01.2011 10:17:00) [0]

Вообще то не мешало бы иметь СУБД

← →
KSergey © (2011-01-19 15:41) [8]

> KSergey © (19.01.11 12:12) [5]

Блин, в пример я совсем забыл добавить проверку на то, что данный патч уже установлен!
тогда ничего делать не надо, понятно
Просто выйти с нотификацией (без ошибки)

← →
MsGuns © (2011-01-19 16:14) [9]

>Проходимец (19.01.11 11:48) [4]
>Тогда самое правильное решение - уволить проектировщиков.

Толпу народа надо увольнять. Причем народа очень грамотного :)

← →
Юрий Зотов © (2011-01-19 16:18) [10]

Изменение структуры БД может быть вызвано разными причинами. Но кто мне скажет, почему такая необходимость возникает часто?

← →
Игорь Шевченко © (2011-01-19 16:19) [11]

> Но кто мне скажет, почему такая необходимость возникает
> часто

Бизнес не стоит на месте

← →
Ega23 © (2011-01-19 16:25) [12]

> Но кто мне скажет, почему такая необходимость возникает
> часто?

Часто - понятие относительное. Раз в полгода - это часто? Раз в месяц? В неделю?

← →
12 © (2011-01-19 16:33) [13]

А заменить хранимку - изменение структуры БД?

← →
Ega23 © (2011-01-19 16:37) [14]

> А заменить хранимку - изменение структуры БД?

Скорее да чем нет. Впрочем, философский вопрос. Ежели select из хранимки СУБД разрешает делать, а возвращаемый результат поменялся - то изменение структуры. Если просто в логике работы - то, вроде как, структура не затрагивается.

← →
wicked © (2011-01-19 18:35) [15]

> > А заменить хранимку - изменение структуры БД?
>
> Скорее да чем нет. Впрочем, философский вопрос. Ежели select
> из хранимки СУБД разрешает делать, а возвращаемый результат
> поменялся - то изменение структуры. Если просто в логике
> работы - то, вроде как, структура не затрагивается.

можно обобщить
если менялся интерфейс хранимки (параметры или возвращаемые значения), то тогда менялась структура

в противном случае - можно считать, что менялась внутренняя логика

> Проходимец (19.01.11 11:48) [4]
>
> > структура БД меняется часто
>
> Тогда самое правильное решение - уволить проектировщиков.
>

Полностью согласен, не смотря на грамотность народа...
ЗЫ
В чьей грамотности можно вполне усомниться.

> Johnmen © (19.01.11 19:51) [16]
>
>
> > Проходимец (19.01.11 11:48) [4]
> >
> > > структура БД меняется часто
> >
> > Тогда самое правильное решение - уволить проектировщиков.
>
> >
>
> Полностью согласен, не смотря на грамотность народа...
> ЗЫ
> В чьей грамотности можно вполне усомниться.

не согласен, судя по:

> Добавляются новые таблицы, добавляются поля в существующие
> таблицы, добавляются внешние ключи и индексы. Клиентское
> приложение соответствующим образом модифицируется.

расширяется функционал приложения, потому об ошибках проектирования вряд ли можно говорить.

> картман © (19.01.11 22:42) [17]

Если все изменения БД состоят лишь в том, что "добавляются новые таблицы, добавляются поля в существующие таблицы, добавляются внешние ключи и индексы", то очевидно, что все это элементарно делается скриптами и тогда непонятно, откуда вообще появился сабж.

Тем не менее, он появился - значит, речь может идти и о более серьезных изменениях, причем частых. А вот это уже сильно похоже именно на ошибки проектирования.

Какие все умные и безгрешные здесь, оказывается.
Ну и телепаты наконец-то вернулись из отпуска.

Неизвестный юзер, ты хоть здесь появишься исчё еще нет?

> Какие все умные и безгрешные здесь, оказывается.

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

← →
Unknown_user (2011-01-21 21:57) [21]

Спасибо всем за советы. Особенно благодарен KSergey за приведенный пример скрипта. Вы окончательно убедили меня в том, что инкрементных патчей не избежать.

В изменении структуры БД виноваты не проектировщики, а заказчики. Не выдав окончательных требований (полного ТЗ) они уже хотят видеть работающее приложение. Нас такая ситуация сильно раздражает, но поделать ничего не можем. И изменения структуры БД действительно частые (бывает и по несколько раз в неделю) и не всегда лишь в сторону расширения функционала.

>... но поделать ничего не можем.

В том то и беда, что и не надо ничего делать.
Так их вечно доить можно за "доделку/переделку"
Если же это все делается бесплатно - в рамках суммы договора, то ССЗБ

Изменение структуры БД Найти похожие ветки