miwa
Full Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Andryshok
Цитата:| в моем случае не нужно заполнять данными никакие таблицы, |
Гарантированно никогда? Никогда не будет новых not null столбцов? Никогда не появится новый справочник с эталонными значениями? Никогда не надо будет провести денормализацию на основании уже имеющихся значений?
Не смешите мои тапочки ©
Цитата:| обновление должно быть по схеме : например из состояния В сразу в состояние Z . т.е. всегда при обнове выполняется обновление до последней версии |
А оно и так всегда будет обновляться до последней версии. Хранить в базе данных ее текущую версию и при поновлении запускать поочередно скрипты, которые сделают всю работу по обновлению.
Цитата:| хранить истории из скриптов версий X, Y, Z - более чем неудобно |
Более, чем удобно. Всегда видно, что и когда изменилось; всегда можно отследить на каком этапе у одного-единственного клиента из пары сотен что-то пошло не так. Плюс скрипты отлично укладываются в систему контроля версий, в отличии от бинарной БД.
Только не говорите, что я сейчас еще должен буду убеждать о необходимости использовать системы контоля версий.
Цитата:| причем тогда еще нужно отслеживать в каком состоянии в данный момент база клиента - например А или С и соответственно применять нужные скрипты. |
Да, конечно, написать что-то типа (дельфи-псевдокод)
Код: FindFirst(*.sql, faAnyFile, CurrentFile);
while FindNext(CurrentFile) do
if GetVersion(CurrentFIle) > GetVersion(Database)
then UpdateDbFromFile(CurrentFIle);
FindClose(CurrentFile);
|
это значительно намного сложнее, чем написать коннесктор UniDAC для Database Comparer VCL.
Kmich
Цитата:| У меня одни и теже обновления могут выполняться по 100 раз а вся нагрузка на Firebird он сам отслеживает есть ли поле в таблице или нет, соответственно если есть такое поле или таблица то ошибку выдает и я делаю откат. |
А вот так я бы не советовал делать. Независимо от того, сам ли Firebird отслеживает, или Oracle, или MySQL какой-нибудь. Запросто можно нарваться на вариант типа: создать новый временный столбец,
скопировать данные из существующего с каким-то изменением (хоть lowercase или смена кодировки для строк, хоть какой-нибудь +1900 для дат, хоть +1 для чисел), грохнуть старый столбец, на его место всунуть новый с измененными данными. Такой вариант всегда будет отрабатывать без ошибок и всегда будет менять данные. И это - только первое из того, что пришло в голову, не вникая в нюансы конкретной СУБД или предметной области. |
) не придумал.