** Оговорка: я сталкивался с такой ситуацией в прошлом, но в PHP.Концепции для PHP, но могут быть применены к Perl с некоторой мыслью.
Я играл с идеей добавления триггеров к каждой таблице AFTER INSERT
, AFTER UPDATE
, AFTER DELETE
, чтобы выполнить то же самое.Проблема была в следующем:
- триггер не знал пользователя 'admin', только пользователь db (
CURRENT_USER
) - Самая большая проблема заключалась в том, что это не таквозможно добавить эти триггеры во все мои таблицы (я полагаю, я мог бы написать скрипт для добавления триггеров).
- Поддержка триггеров.Если вы измените способ отслеживания, вам придется обновить все триггеры.Я полагаю, что наличие вызова триггера для хранимой процедуры в основном решило бы эту проблему.
В любом случае, в моей ситуации я обнаружил, что лучший способ действий был на уровне приложений (не на уровне БД):
- создайте слой абстракции БД, если вы этого еще не сделали (класс, который обрабатывает все взаимодействия с базой данных).
- создайте функцию для каждого действия (вставка, обновление, удаление).
- в каждой из этих функций после успешного вызова запроса добавьте еще один запрос, который вставит соответствующую информацию в вашу таблицу отслеживания
Если все сделано правильно, любое действие, которое вы выполняете для обновлениялюбая таблица будет отслежена.Мне пришлось добавить некоторые переопределения для определенных таблиц, чтобы они не отслеживались (например, какой смысл отслеживать вставки в таблицу track_table).Вот пример схемы отслеживания таблиц:
CREATE TABLE `track_table` (
`id` int(16) unsigned NOT NULL,
`userID` smallint(16) unsigned NOT NULL,
`tableName` varchar(255) NOT NULL DEFAULT '',
`tupleID` int(16) unsigned NOT NULL,
`date_insert` datetime NOT NULL,
`action` char(12) NOT NULL DEFAULT '',
PRIMARY KEY (`id`),
KEY `userID` (`userID`),
KEY `tableID` (`tableName`,`tupleID`,`date_insert`)
) ENGINE=InnoDB