Если таблица с кучей данных. В нее нужно добавить столбец вида


Если выполнять это действие "визуально", щелкая мышкой в IBExpert на вкладке со структурой таблицы, но "умный" эксперт после добавления столбца рассказывает страшную сказку с эпилогом о том, что необходимо следом пульнуть запрос вида:


При этом, если отменить такую "инициализацию", ограничившись одним alter'ом то при переключении на вкладку Данные прекрасно отображается и новый столбец, и (для уже существующих в таблице строк) дефолтные данные "12345" в нем.

Потому вопрос - нужно ли принудительное обновление уже существующих строк дефолтным значением при добавлении в таблицу нового столбца с параметрами "NOT NULL" и "DEFAULT xxx"?

зы. вопрос навеян тем, что Firebird 2.5.2 на не самом медленном SSD уже часов 10 пытается вот так вот обновить по "подсказке" эксперта добавленный в крупную табличку (млн 60 строк) столбец, сожрав при этом 10 ГБ памяти. и х.з. когда он закончит...

Dimitry SibiryakovBLOB с дефолтом? Ну, вы, батенька, изверг...а в чем проблема? и какая разница, будет столбец INTEGER'нутый или VARCHAR'нутый?

Dimitry SibiryakovНужно. То, что ты видишь на вкладке данных это призраки. Сменишь дефолт они тоже поменяются.А если после добавления такого столбца (без апдейста старых строк) сделать b/r - для блобов в новом столбце выделятся реальные blob id?

kdvС какой радости при бэкапе-ресторе вдруг твои null превратятся в default, непонятно.у вдруг? :)
зы. в реальности default - это пустые строки

hvladfd00chА если после добавления такого столбца (без апдейста старых строк) сделать b/r - для блобов в новом столбце выделятся реальные blob id?Даполучается, при этом обновление существующих строк в новом столбце будет "бесплатным", ведь время бекапа или рестора не увеличится после приведенного alter'а на 10+ часов?

к тому же на b/r после такого изменения структуры я, похоже, все равно попадаю, ибо Firebird как-то нехорошо начинает тормозить после внесения таких правок в таблицу (и в итоге - простой на 12 часов для update + 2 часа на backup + 4-6 часов на restore)

hvladесли ты не собираешься менять этот default, то я вообще не вижу причин для update'ану, с учетом полученных знания - я тоже))hvladФакты есть ?если до ночи таблица успеет апдейтнуться - посмотрю, сколько занимает типичные мелкие вставки и апдейты из клиентского софта (по сравнению с доапдейченной и ресторнутой таблицей)

но бекап такой базы (читай - селект), имхо, будет все же дольше))

hvladМного временных блобов может быть больно, ты это видишь на примере своего апдейта.тогда уж бекапа

а вообще, что движок делает при таком обновлении столбца? почему апдейт 1 столбца в 60 млн строк занимает 10+ часов, при этом (по показаниям Диспетчера задач) сервер вычитал с диска в 1.5 раз больше данных, чем занимает база и раза в 3 больше, чем занимает таблица? на обновляемом столбце индексов нет, другие индексы в базе (которых больше десятка) не модифицируются при этом?

Dimitry Sibiryakov, а можно я дождусь, пока апдейт доработает?))

любопытства ради: это понятиеDimitry Sibiryakovфрагментация записейа также "нулевая польза от высокоселективных индексов" для SSD разве актуальны?

Dimitry Sibiryakovfd00chа можно я дождусь, пока апдейт доработает?))
А зачем? Да и к тому же: ты ведь сделал резервную копию базы перед своими экспериментами?..можно я не буду отвечать на эти вопросы?)) в теории бекап есть, но там свои ошибки, вызванные запуском write-транзакций при аналогичном добавлении и обновлении другого столбца

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