iBase.ru Forum

СУБД FIREBIRD
Как правильно организовать триггер, а также таблицу в которой будет вестись лог, статистика некоторых действий юзера. Например будем отлавливать все, что пользователь вносит в таблицу DEVICES.
Для этого создаём таблицу EVENTS, в которой имеется первичный ключ PK_ID, FK_ID внешний ключ на первичный ключ таблицы DEVICES. Также имеется поле UID, в котором должно хранится имя юзера, поле E_DATE соответственно для хранения даты внесения. В таблице DEVICES у нас имеется поле NAME, в котором хранится имя добавляемого устройства.
Создаём процедуру GETUID, которая возвращает нам current_user, также мы можем получить current_date и т.п.
Теперь что касается триггера, я не совсем понимаю весь принцип, ибо Firebird это моя первая субд, с которой я так сказать и начал своё образование в этой сфере, триггер может выполняться перед INSERT и после INSERT, нам который нужен? Далее, допустим у нас имеется триггер, который имеет свойство AFTER INSERT, что мы пишем в теле: insert into events values(GETUID,GETDATE);
Понимаю, что не правильно вызывать таким образом процедуры, необходимо делать execute procedure GETUID, но, целесообразно ли вообще создавать процедуру для того, чтобы просто получить current_user, current_date ? Ведь в теле процедуры у меня содержиться всеголишь select current_user from rdb$database, по той причине, что я не знаю, как корректно вставить подобный запрос в триггер.
Я не прошу конкретного мануала, пошаговых действий. Просто подскажите, я на правильном пути? Будет ли счастье?
Заранее благодарен за любую информацию.

щастье конечно будет, правильной дорогой идете товарищ.
Почитай статейки по триггерам и сам во всем разберешся.

А я для этой цели использовал POST_EVENT в триггере After Insert, ну это для того штобы вести лог запуска юзером клиентских приложений и ведения лога этого самого захода на сервере.

процедуру в таком случае - нецелесообразно.
достаточно все написать в триггере. по триггерам см. базу примеров employee и книжку Мир Interbase.

TAV POST_EVENT я тоже использую, но только для подтверждения транзакции, в клиенте перехватываю это событие и вывожу сообщение о том, что оно поизошло. Если POST_EVENT срабатывает, его получают все? Может поподробнее, как ты это применяешь для ведения лога

вобщем да... оговорка, POST_EVENT можно использовать только для мониторинга какого либо события пришедшего от триггера, поймать его можно только в приложении.

А лог я веду так, при заходе клиента запрашиваеться пароль, есть спец табличка паролей и юзер неймов, если пароль найден значит запускаемся и в табличку лога пишем запись с текущей датой и юзер идом, при добавлении этой записи происходит POST_EVENT, но это просто чтобы знать, что кто-то работает в данный момент с клиентской программой и отоброжать это в приложении-мониторе. При выходе юзера тоже самое (только с другим евент идом в базе лога). Т.е. все реализуеться программно в клиентском приложении.

TAV писал(а):А лог я веду так, при заходе клиента запрашиваеться пароль, есть спец табличка паролей и юзер неймов, если пароль найден значит запускаемся и в табличку лога пишем запись с текущей датой и юзер идом, при добавлении этой записи происходит POST_EVENT, но это просто чтобы знать, что кто-то работает в данный момент с клиентской программой и отоброжать это в приложении-мониторе. При выходе юзера тоже самое (только с другим евент идом в базе лога). Т.е. все реализуеться программно в клиентском приложении.

1) Зачем тебе еще одна табличка паролей и юзер наймов?
2) Как быть с внезапным отваливанием юзеров - клиент у тебя ничего не сделает (не успеет)
3) Нафига вообще логировать, кто и когда законнектился/отконектился? Если уж логировать, то логировать операции над данными (и желательно с возможностью отката в критических местах).

1. Табличка нужна для ограничения входа юзеров (сам коннект идет под одним юзером и паролем).
2. Ну и ладно - пускай отваливаються, не для того это надо. А надо это для того чтобы просто знать, что кто-то прогу использует и когда, так сказать, надзиратель над надзирателем.
3. Клиент только читает, ничего не меняет в базе.