aidynchik,

при версионности если блоб меняется, или "еще раз прицепляется", то он будет копироваться полностью каждый раз. Если меняется только запись, то ссылка на блоб остается старая, так что блоб не копируется.
Есть аспект с временными блобами
а что касается вообще места - то БД в ФБ 2.5 увеличивается не "постранично", а блоками, см. параметр
DatabaseGrowthIncrement в firebird.conf.

если в БД добавить тучу данных, а потом удалить, то после долгое время БД увеличиваться не будет, т.к. пустое место будет использоваться, и т.д. Так что я советую не париться по этому поводу, за исключением вот такой темы
http://www.ibase.ru/dbgrowth/

aidynchikВставлять записи сразу в постоянную таблицу не закоммичивая транзакцию?
мы (вроде) тут не очень поняли вашу исходную идею, т.е. на чем вы собрались экономить.
aidynchikВроде как мусор из-за GTT скапливаться не должен.
gtt у Firebird находятся вне базы данных. Соответственно, про мусор речь не идет.
Если данные вставлять в обычные таблицы, то тоже про мусор не может быть и речи - откуда мусор?

Единственное оправдание вашему решению - это если вы вставляемые данные перед переносом из gtt в БД обновляете раз по 20, причем в разных транзакциях. Однако я не очень понимаю, по каким причинам это может произойти, если речь идет об "окне редактирования сотрудника". Ладно бы если эти редактирования были "сохранением" промежуточного редактирования. Так ведь максимум жизни данных gtt - это в коннекте. А если приложение отвалилось, то и данные из gtt уже не будут видны.
Так зачем здесь gtt?

aidynchik Я просто не вижу другого выхода при добавлении фото и вообще реквизитов больше одного (например телефоны), которые падают в отдельную таблицу и имеют ссылку на сотрудника.
опять я не понимаю. "не вижу другого выхода" - почему? Представьте себе, что в ФБ нет gtt. Что дальше? Случится катастрофа?
aidynchikЕсли вставлять BLOB сразу в обычную таблицу и не коммитить, то есть риск, что транзакция растянется, вдруг юзер посреди редактирования сотрудника пошел пить чай с концами. Это не будет длинной транзакцией? Или я туплю, и чего-то не понимаю в транзакциях?
Во-первых, длинные транзакции действительно зло. Значит, надо сохранять данные в таблицы только после того как пользователь нажмет кнопку "сохранить" (и именно в этот момент стартовать транзацию). А не в самом начале.
Еще раз повторю - с точки зрения потери данных при сбое приложения до сохранения, что гтт, что обычная таблица равнозначны.
Если же вы хотите что-то сохранять в промежутке - тогда да, надо использовать обычные таблицы, и периодически делать коммит.
Во-вторых, вы с блобами что-то попутали.
В статье идет речь про МАССОВЫЕ временные блобы. У вас речь про фотографию сотрудника, ОДНУ. Где вы тут проблему увидели, вообще непонятно.
aidynchikНо как быть при создании нового сотрудника? Как ее заполнять?
ну, вы же собираетесь реально создать нового сотрудника, так? Не баловством же пользователь программы занимается?
Так получите id, создайте сотрудника, сделайте коммит, и добавляйте себе другие данные к этому сотруднику.
Или, получите id, создайте сотрудника, добавляйте данные, и потом делайте коммит.

Кстати, по поводу "пошел пить чай с концами" - вы можете поставить в программе таймер по неактивности пользователя, и через 10-15 минут предупреждать, что несохраненные данные будут потеряны. Красными буквами на весь экран.

aidynchik1) Сгенерил ID
2) При нажатии "добавить фото" - вставил фото с этим id
3) при нажатии "сохранить" вставил сотрудника.
Но это же не логично
нелогично - это когда вы почему-то переставили местами пункты 2 и 3. Кто вам сказал, что надо добавить фото фиг знает к кому, т.е. к еще несохраненному сотруднику?
Как вы все то же самое делаете в gtt? почему вы не можете то же самое делать с обычными таблицами?
О каком вообще массиве блобов "передаваемом в процедуру" идет речь? Вы что, в gtt тоже передаете массив блобов?

Короче. В обычных таблицах вы можете делать все то же самое, что и сейчас с GTT. Боязнь какого-то там мусора из-за длинных транзакций - так вы не понимаете природу версионности. Любая активная read-write транзакция, даже если она ничего не делает - ни в гтт, ни в обычные таблицы ничего не пишет - все равно является причиной накопления версий в БД.
Прочитайте
http://www.ibase.ru/mga/
Если уже читали - второй раз, третий, и т.д.

Вы себе чего-то там придумали, начали чесать левое ухо правой рукой, и теперь спрашиваете "как же мне быть"?

aidynchikя понял, все мне тут предлагают, после отработки ХП, запускать отдельные инсерты на вставку блобов
1. откуда взялась ХП?
2. почему вы не можете с обычными таблицами работать так же, как сейчас работаете с гтт?