Об особенностях FireBird

← →
Ega23 © (2008-01-21 11:25) [0]

Всё-таки, наверное, это тема для "Прочее", нежели для "Базы", т.к. тут филосовские аспекты затрагиваются.
В общем, вопрос такой: каким образом Вы поддерживаете структуру БД в случае большого количества инсталляций.
Сейчас поясню на примере MSSQL: создаётся какая-нибудь информационная система. Под неё создаётся модель БД (таблицы, связи, ХП, триггеры etc). Разработка модели ведётся какими-то средствами (в моём случае отдаю предпочтение PowerDesigner + Query Analyzer). В какой-то момент принимается решение, что данная система "устаканилась", возможно появляются первые инсталляции системы у клиентов.
В этом случае дальнейшие изменения в структурах БД ведутся не через Reverse Engeneer, а патч-скриптом. Например:
if not exists (select 1 from sysobjects where id = object_id("TVHistory") and type = "U") begin create table TVHistory ( UNID int Identity(1,1) not null, EventGUID uniqueidentifier not null, DatIn datetime not null, DatOut datetime not null, RegDatIn datetime not null, CamObjID int not null, CamObjNam varchar(255) not null, FileNam varchar(255) not null, FileNot varchar(255) not null, StatFl tinyint not null, constraint PK_TVHISTORY primary key (UNID) ); Print("Table created: TVHistory"); end; go

Таким образом, для обновления структуры БД ведётся один (или несколько) патч-скриптов, в которых аккуратным образом прописывается создание таблиц, связок, изменение структуры, вставка каких-либо записей в справочники и т.п.

Далее, всё это дело прогоняется через isql + некий свой графический интерфейс на реальной базе. Т.е. процесс обновления БД у клиента происходит так: приехал на объект, сделал бэкап, запустил прогон патч-скриптов, запустил прогон процедур-триггеров, проверил работоспособность.

По такой идеологии работаем уже достаточно давно с MSSQL.
Вопрос: практикуется ли подобная схема обновления стуктуры БД в случае FireBird? Какие могут быть "подводные камни"?

← →
Игорь Шевченко © (2008-01-21 11:34) [1]

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

← →
Ega23 © (2008-01-21 11:39) [2]

> Мы делаем проще - вводим понятие версии схемы. Соответственно,
> каждый патч поднимает версию и работает только в случае
> соответствия версии схемы той, для которой предназначен
> патч. Сам патч тоже изменяет (поднимает) версию.

Да можно и так. Даже, пожалуй, более логичный способ (хотя нюансы также есть).
Но меня больше интересует сам механизм поднятия структуры БД до определённой "версии схемы".

← →
Reindeer Moss Eater © (2008-01-21 11:47) [3]

Особенность вроде всего одна - ddl в транзакциях

← →
Игорь Шевченко © (2008-01-21 11:57) [4]

> Но меня больше интересует сам механизм поднятия структуры
> БД до определённой "версии схемы".

SQL-скрипт :) Или он же, встроенный в "обновлятель".

← →
PEAKTOP © (2008-01-21 12:00) [5]

> Ega23 © (21.01.08 11:39) [2]

Если тебя интересует, как можно создать UpdatePack на "голом" SQL, чтобы скормить его какому-нибудь SQL-Interpretier, то можно извратиться с EXECUTE BLOCK;

SET TERM ^ ; EXECUTE BLOCK AS DECLARE VARIABLE P_REL_NAME DOMN$PSTRING; DECLARE VARIABLE P_SQL DOMN$PSTRING_2048; BEGIN IF(NOT(EXISTS(SELECT R.RDB$RELATION_ID FROM RDB$RELATIONS R WHERE (TRIM(R.RDB$RELATION_NAME) = "MY_TABLE" ))))THEN BEGIN P_SQL = "CREATE TABLE MY_TABLE ("|| " ID INTEGER "|| " ,NAME VARCHAR(255) "|| ")"; EXECUTE STATEMENT P_SQL; END END ^ COMMIT ^ /* ВАЖНО ВЫПОЛНЯТЬ ПОСЛЕ КАЖДОГО БЛОКА */

Идея основана на недокументированной возможности конструкции EXECUTE STATEMENT выполнять не только DML, но и DDL скрипты. А недокументированной - чтобы дети базы рабочие не укладывали :).

В следующих версиях возможность выполнять DDL через EXECUTE STATEMENT Дима Еманов обещал не сносить. В документации эта возможность отражена не будет.

← →
Ega23 © (2008-01-21 12:02) [6]

> PEAKTOP © (21.01.08 12:00) [5]

О!
Похоже то, что нужно!
Спасибо!

← →
turbouser © (2008-01-21 12:05) [7]

> По такой идеологии работаем уже достаточно давно с MSSQL.
>
> Вопрос: практикуется ли подобная схема обновления стуктуры
> БД в случае FireBird? Какие могут быть "подводные камни"?
>

У меня сделано так:
1) Делается резервная копия БД
2) Делается сравнение утилитой IBECompare от HK-Software БД пользователя с "эталонной" БД (без данных)
3) Выполняется скрипт, полученный в результате сравнения
4) Выполняются дополнительные скрипты
5) В случае каких-либо ошибок исходная БД восстанавливается
6) Сохраняется протокол обновления

Этим всем занимается отдельная программка в инсталляшке, юзеру достаточно
только указать целевую БД и ввести админский пароль.

← →
PEAKTOP © (2008-01-21 12:14) [8]

> Ega23 © (21.01.08 12:02) [6]
> > PEAKTOP © (21.01.08 12:00) [5]
>
> О!
> Похоже то, что нужно!
> Спасибо!

Чует мое сердце: дал ребенку гранату ...

← →
ZeroDivide © (2008-01-21 12:23) [9]

Почти так же как в Игорь Шевченко © (21.01.08 11:34) [1], только старый exe-шник, ругнувшись на соответствие метаданных версии клиента, все таки дает себя запустить.

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

Подводных камней вроде нет. База может мутировать как угодно. Правда, обычно, если изначально была спроектирована грамотно, то drop"а практически не бывает, в основном схема БД только расширяется - этим и обусловлена возможность запуска старого экзешника на новой версии метаданных. (Хотя я пользователей предупреждаю об отказе от ответственности при порче/потере данных при таком режиме работы)

← →
Desdechado © (2008-01-21 12:25) [10]

Подводных камней предостаточно.
Вброшу один - т.к. метаданные кэшируются при подключении, то изменение структуры БД с данными наживую может требовать переподключения в определенные моменты, например:
1. при попытке создания внешнего ключа на только что созданный первичный
2. при попытке удаления первичного ключа при только что удаленном внешнем.
Эти попытки будут неуспешными, т.к. кэш метаданных содержит устаревшую информацию.

PS
Недавно тут было обсуждение методики обновления структуры БД, поищи.

Desdechado © (21.01.08 12:25) [10]

Мы например вживую не обновляем. Ибо нефиг. Впрочем, можно поступить, как Windows - сделать обновления и сказать, что надо перезагрузиться.

> Мы например вживую не обновляем. Ибо нефиг. Впрочем, можно
> поступить, как Windows - сделать обновления и сказать, что
> надо перезагрузиться.
>

+1. Не стоит живое обновление геморов реализации.

Спасибо всем ответившим, выводы сделаны, буду ковыряться дальше.

> Мы например вживую не обновляем. Ибо нефиг.
Под "наживую" я имел в виду не при подключенных пользователях, а при наличии данных в БД (живая БД, а не болванка-прототип). Потому как при обновлении пустой БД описанные мной камни могут не проявляться.

Desdechado © (21.01.08 14:07) [13]

Данные безусловно наличествуют. Но проблем с "кешированием метаданных" мы как-то не наблюдали.

Об особенностях FireBird Найти похожие ветки