ALTER TABLE SQL_LOG ADD CONSTRAINT PK_SQL_LOG PRIMARY KEY (ID);
Написал программку, которая автоматом генерит текст триггеров. Триггеры,
на
основании значений переменных .old и .new создают текст sql оператора,
который обеспечит те же изменения, что происходят с текущей строчкой, и
заносят его в табличку SQL_LOG.
Не будет это работать. Блобы и double мимо кассы пролетят
Ну блобы мне вообщем-то пофиг, игнорирую их. И массивы тоже.
А с double что? Я его значение в виде строки для sql оператора получаю как
cast(new.fld as varchar(24)). В принципе в моей базе вроде как и нету их.
Нумериками обхожусь. Но вдруг понадобиться.
Поизменял данные в IBExperte. Все вроде
работает, скрипт генериться. Но заметил одну особенность - при коммите
транзакции, даже если изменил одну запись, происходит небольшая задержка.
Совсем небольшая, но все-таки на глаз уловимая. При этом обязательно диск
дергается. Вот закрались сомнения, ежели все это внедрить - не получу ли
ощутимых тормозов при многопользовательской работе?
Экспериментировал на FB 2.0. На своем компьютере, под XP.
Ну и залей лимон записей в логгируемую таблицу - узнаешь ;)
Ну при вставке, по идее объем таблицы на быстродействие особо сильно влиять
не должен. Разве что вставка ключа в индекс.
А вообще, все это из хотелки восстановить состояние базы на любой момент
времени. Вообщем планирую еженощно вместе с backup-ом выгружать скрипт в
файл и чистить лог. Так что объемы не сильно пугают. А насторожила эта самая
задержечка в момент коммита. Может это с varchar(4096) как-то связано.
With b/r. Gleb.
