-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Организация журналирования пользовательских событий
- Автор темы rotoZOOM
- Дата начала
KorP
Новичок
тогда какого Х ты мне голову морочишь?
чем хранение в строке тогда тебя не устраивает, если тебе её только вывести надо?
weregod
unserializer
я бы попробовал так:
log_transaction: id, id_actor, id_entity, date (у сущности, например товара, могут изменяться несколько характеристик сразу, они оборачиваются в общую "транзакцию")
log_event: id, id_transaction, id_property, id_action, old_value, new_value (у товара изменили цену и скидку, докинулось две записи)
log_dictionary_entity: id, name (товар, новость, прочее)
log_dictionary_action: id, name (список возможных действий, если действие производится над самой сущностью (например, удаляется товар), на такие случаи свои действия типа "delete_entity")
log_dictionary_property: id, name (список возможных характеристик)
log_transaction: id, id_actor, id_entity, date (у сущности, например товара, могут изменяться несколько характеристик сразу, они оборачиваются в общую "транзакцию")
log_event: id, id_transaction, id_property, id_action, old_value, new_value (у товара изменили цену и скидку, докинулось две записи)
log_dictionary_entity: id, name (товар, новость, прочее)
log_dictionary_action: id, name (список возможных действий, если действие производится над самой сущностью (например, удаляется товар), на такие случаи свои действия типа "delete_entity")
log_dictionary_property: id, name (список возможных характеристик)
rotoZOOM
ACM maniac
Вот такие мысли на текущий момент.
Обрабатывать данные порционально, в небольших временных интервалах, то есть за раз, скажем, в процессинге будут учавствовать данные не более, чем за неделю.
Структура будет гибридной.
events {id, date, user_id, type_id, content}
type_id - категория события (они более менее фиксированные и их не более 50-100: удаление пользователя, добавление пользователя, редактирование пользователя, удаление группы, добавление группы, редактирование группы, смена прав для группы и т.д.).
content - сериализованный объект события, базовый тип которого LogEvent.
Фильтр будет состоять из даты, пользователя, категорий событий, а так же динамически сгенерированных фильтров конкретных классов событий, например "редактирование флага активации пользователя".
При использовании фильтров только по дате, пользователю и категориям событий фильтрация будет осуществляться БД, что, естественно, ускорит выборку.
Как пользователь выбирает что-то из динамических фильтров конкретных классов, выборка БД осуществляется только по дате (ну может еще и пользователю) и фильтр уже применяется для каждой записи.
Как то так, сумбурно.
Посмотрим, что из этого выйдет. Может быть будут корректировки по мере процесса разработки.
Обрабатывать данные порционально, в небольших временных интервалах, то есть за раз, скажем, в процессинге будут учавствовать данные не более, чем за неделю.
Структура будет гибридной.
events {id, date, user_id, type_id, content}
type_id - категория события (они более менее фиксированные и их не более 50-100: удаление пользователя, добавление пользователя, редактирование пользователя, удаление группы, добавление группы, редактирование группы, смена прав для группы и т.д.).
content - сериализованный объект события, базовый тип которого LogEvent.
Фильтр будет состоять из даты, пользователя, категорий событий, а так же динамически сгенерированных фильтров конкретных классов событий, например "редактирование флага активации пользователя".
При использовании фильтров только по дате, пользователю и категориям событий фильтрация будет осуществляться БД, что, естественно, ускорит выборку.
Как пользователь выбирает что-то из динамических фильтров конкретных классов, выборка БД осуществляется только по дате (ну может еще и пользователю) и фильтр уже применяется для каждой записи.
Как то так, сумбурно.
Посмотрим, что из этого выйдет. Может быть будут корректировки по мере процесса разработки.
Я просто оставлю это здесь: http://dklab.ru/lib/dklab_rowlog/
weregod
unserializer
В своей структуре исходил из http://phpclub.ru/talk/threads/Организация-журналирования-пользовательских-событий.70904/page-2#post-633469
Если таки-захотят фильтровать по тому, с чего на чего поменялось, будет айс, с другой стороны структуру можно именно к тому моменту, когда захотят, только апдейтер данных придётся написать.
Если таки-захотят фильтровать по тому, с чего на чего поменялось, будет айс, с другой стороны структуру можно именно к тому моменту, когда захотят, только апдейтер данных придётся написать.