IB/FB
Есть триггеры before и after действия. Подключаются на таблицы и view, правда, view я не пользуюсь, поэтому ничего о них сказать особого не могу.
Триггеров на системные события как таковых нет, но при желании всегда можно сделать их на системные таблицы - по крайней мере на DDL отрабатывать будут. Честно говоря, не знаю, для чего это нужно.
Триггер отрабатывает для каждой записи, можно установить порядок их выполнения. Естественно, возможно несколько триггеров на одно действие, лишь бы имена различались.
По поводу применения триггеров before - у меня такие же непонятки насчет применения instead-of. А в before обычно выполняют следующие действия:
1. Заполнение дополнительных полей данными, например, автоинкремент или преобразование значения поля в верхний регистр и тд. Вычислимые поля хотя и есть, но не индексируются, поэтому часто удобно просто создать служебное поле, заполнить его значением другого в верхнем регистре - и готов case insensitive поиск по индексу.
2. Дополнительная проверка ссылочной целостности - foreign key и check отрабатывает между триггерами before & after, но выдает не слишком читабельные сообщения, поэтому удобно проверить в before и выдать исключение вида "А вот так делать нельзя" - в случае исключения дальше не идет и транзакция откатывается

Насчет остального - в триггере before запись в таблице еще не изменена (не вставлена/не удалена), в after - уже сделано. В триггере доступны префиксы OLD & NEW - там, где имеют смысл, соответственно, старое и новое значение поля. Присвоение значения переменным NEW.<FieldName> и тд не вызывает, естественно, новой отработки триггера.

Имхо, наиболее часто встречается триггер вида
create trigger ....
before insert
as
begin
if (NEW.MyField is NULL) then
NEW.MyField = Gen_ID(MyGenerator,1);
end

Удобно - автоинкремент, но отрабатывает только если клиент не задал значения поля.

Насчет вставки NULL в поле not NULL - немного не понял...
Имеется в виду проверка - если значение NULL, то присвоить что-то?
Дело в том, что если поле not NULL и содержит NULL - в IB это никак не пройдет - проверка сработает.

Бррр... Понял - вставляешь Null и хочешь, чтобы в триггере подставилось значение по-умолчанию.
Да, типичная задача для before.
2alexeyvg
Будет он работать, проверка на not null в IB идет после before триггера (вообще все check, not null, foreign key и тд идут после), так что так и подставляется, и не важно, первичный ключ или нет.
И, кстати, наконец-то я понял как применять instead of - ручками вставляешь в таблицы. Удобно, когда, например, view не обновляемое. В IB нет такого :-( В before просто ставишь/уточняешь/проверяешь значения полей, потом запись вставляется в таблицу, делается проверка целостности и отрабатывают триггеры на after, в которых значения полей уже не поменяешь (ошибку, кстати, тоже не дает, просто игнорирует присвоение NEW).

Default - конечно можно, стандарт
А вот identity - такого нет, есть генераторы. И, на мой взгляд, это на порядок удобнее, чем identity.
Приведу пример: На клиенте - связка master-detail, что довольно типично, причем связь по полю с identity. Пользователь вставляет запись в мастера, и хочет вставить записи в detail... А чтобы получить значение поля связи, я должен послать запись на сервер и перечитать запись (хотя бы это поле). - неудобно. С IB - просто, можно дать select Gen_ID(<Generator>,1) from rdb$database - в этой таблице всегда одна запись. Я предпочитаю честно создать процедуру
create procedure MyTable_ID
returns (ID integer)
as
begin
ID = Gen_ID(MyTableGen,1);
end
для каждой таблицы с автоинкрементом, и присваивать значение полю на клиенте. В соединении с упомянутым триггером работает великолепно.
Ну и плюс - генераторы можно применять не только для автоинкремента :-)

Не пробовал... Но дело в том, что после выполнения before будет попытка вставить запись во view, а оно не обновляемое. Избежать этого можно только дав Exception в триггере, а это откатит всю транзакцию :-))