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. почему вы не можете с обычными таблицами работать так же, как сейчас работаете с гтт?

m7m,

я еще добавлю, что вообще, по уму, блобы и прочая ахинея обычно является "вторичной" информацией. То есть, фото сотрудника может не быть, а может быть и фото, и анкета, и еще что-то.
И если по "первичной информации" о сотрудниках будут идти достаточно частые или тяжелые запросы, то все вторичные столбцы лучше вынести в отдельную таблицу, связанную с сотрудниками как 1-1.
Но это так, из разряда "практические советы по проектированию баз данных".

aidynchikПонадобилось вставлять фото. Не имея ID сотрудника на момент его создания
вот опять. Интерфейс создания сотрудника есть. Но оттуда не возвращается его id, потому что раньше он был не нужен.
То есть, это ваш прокол.

Дальше, теперь вы лепите "фото" поперед создания сотрудника. Не надо этого делать. Создали сотрудника, затем добавили фото. У вас же все равно будет и интерфейс ДОБАВЛЕНИЯ фото сотрудникам, поскольку у существующих сотрудников ФОТО НЕТ.
То есть, опять проблема с логикой приложения.

aidynchikв интерфейсе нажимает "Добавить фото" - я кладу блоб во временную таблицу.
зачем во временную таблицу? почему нельзя в TMemoryStream положить фотку, а потом этот стрим записать в блоб сотрудника? Это если фотка копипастится. А если указывается файл с фоткой, так из файла можно блоб прочитать потом.
Зачем вот это телодвижение с сохранением блоба в гтт?
Опять проблема с логикой в приложении.