-
Возможно ли в базе где-то прописать версию подобно ехе-файлу? Для чего это нужно - при обновлении версии программы, надо проверить соответствует ли версия базы данных версии программы. Если нет, то обновить структуру базы.
С уважением.
-
версия базы не зависит от структуры... что наводит на мысль, что это твоя версия... т.е. не версия базы, а версия твоей структуры. ну и пиши ее куда сам хочешь определи табличку и проверяй в ней значение.
-
Надо хранить версию базы в самой базе. А так же весь список миграций.
-
Это понятно, думал может более красивое решение есть.
Еще вопрос, опять же про обновление своей БД. Программа сама создает новую структуру БД, но в старой БД остается пара таблиц с данными, которые надо перенести в новую БД. Использовать SELECt INTO не могу, так как при этом не переносятся индексы и триггеры. Дополнительная проблема в том, что новая БД должна быть создана в том же месте и с тем же именем, что старая.
Пока в голове такой сценарий - копирую данные во временные таблицы в базе temp. Удаляю старую БД. Создаю новую. И в самом делфи в цикле переношу рекорды. Насколько это правильно? Или есть более грамотное решение?
С уважением.
-
Существующие таблицы мигрируют через ALTER TABLE. Индексы обновляют.
-
> [3] yurikon (06.12.11 18:23)
А почему в существующей не делеть обновление структуры? Прочитал текущую версию, накатил обновление до следующей см. > [4] Омлет © (06.12.11 19:07) > Существующие таблицы мигрируют через ALTER TABLE. Индексы обновляют.
-
> Использовать SELECt INTO не могу, так как при этом не переносятся > индексы и триггеры.
Индексы и триггеры - самостоятельные объекты БД, если чё. Они также создаются, изменяются и удаляются.
-
версию хранить можно, но не нужно. потому что.
нужно просто проверять наличие нужных объектов перед их использованием и создавать их если объектов нет.
-
> нужно просто проверять наличие нужных объектов перед их > использованием и создавать их если объектов нет.
Больно монстрообразный скрипт получится.
-
> Медвежонок Пятачок © (07.12.11 14:07) [7] > версию хранить можно, но не нужно.потому что.нужно просто > проверять наличие нужных объектов перед их использованием > и создавать их если объектов нет.
Это даже для простейших случаев не годится.
-
> Это даже для простейших случаев не годится.
Смотря для какой СУБД. Например, тот же MSSQL не строго к зависимостям между объектами базы относится. Соответственно, я совершенно спокойно могу сначала обновить структуру таблиц, а потом пересоздать существующие ХП.
-
Это даже для простейших случаев не годится.
Что не годится?
Ну записал ты версию в таблицу. Затем в базе кто-то што-то изменил. Например удалил добавленное тобой поле. Ты запускаешься, смотришь, версия кошерная, начинаешь селектить. И тут облом. Поля нет. Что ты делаешь? Снова его добавляешь.
-
> Это даже для простейших случаев не годится. Смотря для какой СУБД.
У меня была мультисерверная программа. В том смысле, что работала с ораклом, mssql, access, mysql и фб. И использовался именно такой подход. Очередная новая версия знала, что для нее должны быть созданы такие то новые поля и такие-то новые таблицы. Плюс она помнила всю историю предыдущих апдейтов БД.
В результате можно было взять самый свежую версию и подсунуть ей самую старую базу. И программу это нимало не пугало.
-
> Медвежонок Пятачок © > Очередная новая версия знала, что для нее должны быть созданы > такие то новые поля и такие-то новые таблицы.Плюс она помнила > всю историю предыдущих апдейтов БД.
И как ты определял, какие апдейты уже проведены, а какие нет, если версии у базы нет? С какого места начинать накатывать правки таблиц?
> Затем в базе кто-то што-то изменил. Например удалил добавленное > тобой поле.
Не должен никто в базу лезть, кроме приложения. Иначе ССЗБ и база испорчена. И я не говорил, что проводить миграции надо без проверок.
-
И как ты определял, какие апдейты уже проведены, а какие нет,
я не апдейты проверял, а существование объектов бд, которые появились в ней после того, как разошлась версия программы №1
-
> я не апдейты проверял, а существование объектов бд у меня тоже самое сделано, но с добавкой проверки версии база/"структуры (какой смысл запускать кучу проверок, если версия уже последняя...) после апдейта версия подымается до максимальной а тот момент.
если кто то влез и сам что то наисправлял... то ССЗБ. а так удобно, да, весь апдейт это новый exe подложить, и не заботится о запуске каких то скриптов, их порядка (есть, видел, зависят от номера и запускаются строго по порядку, т.е. сначала проблем себе навыдумывают, а после "обновляторы" пишут...)
-
> И как ты определял, какие апдейты уже проведены, а какие > нет, если версии у базы нет? С какого места начинать накатывать > правки таблиц?
Что-то типа:
if COLUMNPROPERTY(OBJECT_ID(N'[ISSCamera]'), 'SubAddr', 'precision') is NULL
begin
Print 'Добавить поле ISSCamera.SubAddr - подадрес элемента модели';
ALTER TABLE ISSCamera add SubAddr int NOT NULL default 0;
end;
go
if COLUMNPROPERTY(OBJECT_ID(N'[ISSMonitor]'), 'SubAddr', 'precision') is NULL
begin
Print 'Добавить поле ISSMonitor.SubAddr - подадрес элемента модели';
ALTER TABLE ISSMonitor add SubAddr int NOT NULL default 0;
end;
go
if exists (select 1
from sysobjects
where id = object_id('dbo.Abonents')
and type = 'U' and
(COLUMNPROPERTY(OBJECT_ID(N'[Abonents]'), 'AbID', 'precision') is not NULL)
)
drop table dbo.Abonents
go
if exists (select 1
from sysobjects
where id = object_id('dbo.TaskAbPL')
and type = 'U')
drop table dbo.TaskAbPL
go
if not exists (select 1
from sysobjects
where id = object_id('AbonentTyps')
and type = 'U')
begin
create table AbonentTyps (
AbTypCod int not null,
AbTypNam varchar(64) not null,
AbTypLab varchar(64) not null,
AbTypOrd int not null,
AbTypMsk tinyint not null,
AbTypNot varchar(255) not null,
AbTypImg image null,
constraint PK_ABONENTTYPS primary key (AbTypCod)
);
Print('Table created: AbonentTyps');
end;
go
-
> я не апдейты проверял, а существование объектов бд, которые > появились в ней после того, как разошлась версия программы > №1
Это хорошо, если ты можешь перегенерить все триггеры, вьюхи и прочие ХП одним чохом, не заморачиваясь на dependences. Тот же FB такое не позволяет. Точнее, приходится адски геммороится и патч-скрипт разрастается до совсем неприличных размеров (если его очень аккуратно и правильно "вести"). Посему - патч до версии такой-то, а если таблица или поле не существуют, а также кто-то туда своими шаловливыми ручками влез - ССЗБ, sniknik © + 1
-
> Посему - патч до версии такой-то я не проверяю версию патча... проверяю версию структуры, и обновляю единым... который одинаково подымет с версии 1 или с предпоследней до последней... думаю Медвежонок про то и говорит. а вот с версиями патчей, в одной проге поддержке "наелся по самое не могу"...
-
Убиться можно с такими проверками. Тем более в реляционной структуре, когда один апдейт каскадно удаляет таблицы, обновляет другие и патчит третьи, а второй создает таблицу, создает зависимости и заполняет данные на основе предыдущего изменения (а не неизвестного состояния). Многие апдейты решают только последовательные миграции (которые бывают очень сложными), т.к. в сложных системах не сводится все к добавлению несвязанных столбцов и новых табличек.
|