rotoZOOM
ACM maniac
Привет всем!
Хочу спросить совета у опытных разрабов.
Суть задачи.
Есть тематический портал (php, mysql).
Требуется написать систему журналирования (логирования) всех возможных действий зарегистрированных пользователей (в том числе и админов), таких как создание/удаление/редактирование объектов, связей между объектами, фотогаллерей товаров и т.д.
А самое главное - это потом при выводе отчета (списка событий) реализовать систему фильтрации, в которой можно было бы отфильтровать только необходимые события и не показывать остальные, например фильтр:
Дата: с такого по такое-то
Пользователи:
- Иванов;
- Петров;
- Сидоров.
Действия с товарами:
- изменение цены;
- смена главного фото товара;
- смена скидки.
Смысл в том, что этих всевозможных атрибутов фильтрации до ж..., много короче.
Мои мысли по этому поводу:
1. Создать таблицу в БД events {id, event_date, user_id, type_id},
где type_id - это тип события.
Для каждого типа события создать свою таблицу с привязкой по FK к events, например:
event_goods_edit {event_id, .... специфические поля для данного типа события}
Плюсы: фильтрация осуществляется силами БД.
Минусы: при добавлении атрибутов придется менять структуру таблиц, а это значит, что желательно
сразу внести все необходимые поля в структуру, что выльется в кучу таблиц, с большим количеством полей. Генерирование запросов по фильтрам потащат за собой кучу JOIN'ов.
2. Создать таблицу в БД events {id, event_date, user_id, event},
где event - это сериализированный (или сериализованнный) объект базового класса Event.
Для каждого типа события написать свой класс, а фильтрацию осуществлять уже php'ями, а не БД.
Плюсы - фильтр генерируется автоматом при редактировании иерархии классов Event, ООП'эшная структура, не требуется дополнительных дата мэпперов.
Минусы - скорость работы/загрузка сервака при большом диапазоне выборки.
Какие-то такие сумбурные мысли.
В каком направлении копать?
P.S. забыл упомянуть, что каждое событие редактирования должно сохранять предыдущее значение параметра и установленное.
Хочу спросить совета у опытных разрабов.
Суть задачи.
Есть тематический портал (php, mysql).
Требуется написать систему журналирования (логирования) всех возможных действий зарегистрированных пользователей (в том числе и админов), таких как создание/удаление/редактирование объектов, связей между объектами, фотогаллерей товаров и т.д.
А самое главное - это потом при выводе отчета (списка событий) реализовать систему фильтрации, в которой можно было бы отфильтровать только необходимые события и не показывать остальные, например фильтр:
Дата: с такого по такое-то
Пользователи:
- Иванов;
- Петров;
- Сидоров.
Действия с товарами:
- изменение цены;
- смена главного фото товара;
- смена скидки.
Смысл в том, что этих всевозможных атрибутов фильтрации до ж..., много короче.
Мои мысли по этому поводу:
1. Создать таблицу в БД events {id, event_date, user_id, type_id},
где type_id - это тип события.
Для каждого типа события создать свою таблицу с привязкой по FK к events, например:
event_goods_edit {event_id, .... специфические поля для данного типа события}
Плюсы: фильтрация осуществляется силами БД.
Минусы: при добавлении атрибутов придется менять структуру таблиц, а это значит, что желательно
сразу внести все необходимые поля в структуру, что выльется в кучу таблиц, с большим количеством полей. Генерирование запросов по фильтрам потащат за собой кучу JOIN'ов.
2. Создать таблицу в БД events {id, event_date, user_id, event},
где event - это сериализированный (или сериализованнный) объект базового класса Event.
Для каждого типа события написать свой класс, а фильтрацию осуществлять уже php'ями, а не БД.
Плюсы - фильтр генерируется автоматом при редактировании иерархии классов Event, ООП'эшная структура, не требуется дополнительных дата мэпперов.
Минусы - скорость работы/загрузка сервака при большом диапазоне выборки.
Какие-то такие сумбурные мысли.
В каком направлении копать?
P.S. забыл упомянуть, что каждое событие редактирования должно сохранять предыдущее значение параметра и установленное.
