Логирование изменений таблиц нстроек в БД

[Sereja3578]

Всем привет)

Передо мной встала задача, реализовать логирование таблиц настроек в базе данных. Прошу вашего совета, о том, как это лучше реализовать.

Имеющаяся информация и мои размышления:

Изменения в таблицы могут вноситься тремя способами -
1) Через админ панель
2) Через миграции
3) напрямую в БД

В логах по возможности надо хранить по миом изменений информацию о том, кто внес эти изменения, id пользователя, id сессии, ip терминала.

Получение данных о пользователе возможно только при изменениях из админке, когда пользователь авторизован. В остальных случаях будут писаться только изменения.

Вижу пока два варианта решения проблемы

1) Одна таблица на все изменения со следующей структурой
table_name, column_name, old_value, new_value, value_type, date_time, user_id, session_id, ...

Все изменения вносятся на уровне триггера before update. В каждой из таблиц добавляем поле edited_by, которое хранит user_id и записываем в него id пользователя при запросе.

Плюсы
- всего одна таблица, удобно ее отображать в виде грида.

Минусы
- old_value и new_value хранятся в text формате, потом надо их преобразовывать
- При множественном апдейте в миграции, например 10 колонк, будет вызвано 10 инсертов (по инсерту на каждое поле). Получится десять записей на обновление одной строки. А если запросов будет 10000 то и записей будет в 10 раз больше.

2) На каждую таблицу своя таблица логов со следующей структурой -
Все поля таблицы, session_id, terminal_id ...

Так же все изменения вносим на уровне триггера. В каждую таблицу добавляем поле edited_by, которое хранит user_id и записываем в него id пользователя при запросе.

Плюсы
- Один запрос, не важно сколько колонок обновляется - одна строка.
- Простота реализации.
- не нужно преобразовывать типы полей.

Минусы
- Куча гридов.

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

[Sereja3578]

Нашел, наверно почти исчерпывающее объяснение этой темы.
http://www.sql.ru/articles/mssql/2005/0 ... g.shtml#15
Но вдруг идеи еще у вас есть)

[someweb]

1) Одна таблица на все изменения со следующей структурой
table_name, column_name, old_value, new_value, value_type, date_time, user_id, session_id, ...

Убрать column_name и сериализовать всю запись(или только измененные столбцы) не подойдет?

[Sereja3578]

1) Одна таблица на все изменения со следующей структурой
table_name, column_name, old_value, new_value, value_type, date_time, user_id, session_id, ...

Убрать column_name и сериализовать всю запись(или только измененные столбцы) не подойдет?

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

Если интересно, по ссылке выше можете почитать, там в принципе описаны плюсы и минусы оптимальных способов журналирования. Но вообще предлагайте, будем обсуждать и другие варианты)