Регистрация данных: триггеры или особый шаблон проектирования? - PullRequest
1 голос
/ 05 апреля 2011

В настоящее время я работаю над решением для ведения журнала для одного из наших веб-проектов.

  • Язык сервера: PHP 5.2.3
  • База данных: MySQL 5.0
  • Apache 2

Аналогично описанному здесь

Аудит ведения журнала на основе триггера MySQL со сравнениями

мы хотим регистрировать измененные столбцы для существующих записей, вставку новых записей и удаление записей. Для обновлений я должен как-то сравнить старые значения записей БД с теми, что пользователь сохранил. Для вставки регистрация проста, а для удаления мне нужно сначала сохранить старые значения, а затем удалить их в таблице регистрации.

Вопрос, с которым я сейчас сталкиваюсь, таков. Как вы думаете, это лучшее решение.

Регистрация через триггеры на уровне БД или использование подходящего шаблона проектирования на уровне приложения.

Уже существуют некоторые темы по этому поводу, но не рассматривается, что лучше: один (триггеры) или другой (на уровне приложения).

В другой теме предлагается АОП

Какой шаблон проектирования вы бы рассмотрели, когда необходимо ведение журнала?

Я собираюсь с дизайном БД для регистрации # 1, как предложено здесь

Стратегии ведения журнала аудита

где у меня есть отдельная таблица для регистрации для каждой наблюдаемой таблицы. Структура выглядит следующим образом

ID : Integer
COLUMN: String, the column name of the column that changed
OLD_VAL: String
NEW_VAL: String
SOURCE: String, the source which changed the data, currently user and an agent are possible as sources
create_at: DATETIME, then the change occurred

Так что вы, люди, думаете. Учитывая производительность по сравнению с чистым кодом и сокрытием информации, что является лучшим решением для создания системы журналирования, подобной этой.

Любые идеи приветствуются.

Ответы [ 2 ]

2 голосов
/ 05 апреля 2011

Если вы не сделаете это в триггере, вероятность того, что вы не будете регистрировать нужную информацию, довольно близка к 100%. Не все данные изменяются через приложения. Даже когда разработчики думают, что так и будет. Есть моменты, когда большие объемы данных должны быть исправлены или обновлены (например, повышение цены на 10%), и эти запросы будут выполняться непосредственно в базе данных. Если вы введете регистрацию только через приложение, вы пропустите эти изменения. Иногда эти изменения вносятся злонамеренным пользователем или сотрудником и являются одними из наиболее важных для аудита.

1 голос
/ 05 апреля 2011
...