Организация журналирования пользовательских событий

[KorP]

сами эвенты у тебя в справочнике лежат, не надо его никуда класть, надо только поставить e_id, как ты выше написал

таким образом, type_id = 31

 

[rotoZOOM]

Не-не, значение ивентов куда класть? Вот это: "изменил название компании с Цветочки на Ромашки"

 

[rotoZOOM]

Необходимо отображать не только факт того, что "юзер такой-то сменил название компании", но еще и "с Цветочки" (предыдущее значение) "на Ромашки" (текущее значение)

 

[KorP]

ааа, ну клади тогда в свой event_content в основной таблице
т.е. e_id - idшник операции, а event_content - уточнение действия, можно в принципе прям так и писать - "с Цветочки" (предыдущее значение) "на Ромашки" (текущее значение)
тут избыточности нет

 

[rotoZOOM]

В том то и дело, что класть простым текстом не вариант, так как это поле тоже может участвовать в фильтре.
Сейчас оно будет:
id - компании (у которой меняют название)
old_title - старое название
new_title - новое название

В другом ивенте - это:
id - товара
old_discount - старое значение скидки
new_discount - новое значение скидки

и т.д.
То есть если в это поле класть сериализованное значение ивента, как объекта класса, то в итого приходим ко 2 варианту.
Вот я и спрашиваю, есть ли у кого нить опыт сделать это проще.

 

[Breeze]

Breeze, имеется в виду 100-200 типов событий.

да я понял, их тоже имел ввиду

 

[KorP]

я не понимаю - как это поле может участвовать в фильтре? по значению скидки будет фильтроваться? и что оно будет выводить? бред какой то. по типу действия: смена названия, изменение скидки - я могу понять, для этого и есть отдельный справочник

 

[rotoZOOM]

по значению скидки будет фильтроваться?

По значению вряд-ли (если только по диапазону), а вот по конкретной компании или товару или списку компаний/товаров - это будет практически на 90%.

 

[rotoZOOM]

То есть, в фильтре вывода журнала, админ может указать: покажи-ка мне все действия таких-то пользователей, с такого-то по такое-то число, относящихся к такому-то набору компаний (список id компаний).

 

[KorP]

и что это получится?
1-м действием меняем название с А на Б
и машем ручкой твоему фильтру

если у тебя там привязка по компании/товарам - надо их отдельно как то помечать, больше сказать не могу ибо не представляю что ты там делаешь, как, зачем и как оно есть и как должно выглядеть. описывай тогда задачу более глобально, с учётом всех твоих 100500 факторов, что б мы понять могли и ответить на твой вопрос

 

[stopkran]

А добавить в основную таблицу поля old_value, new_value? не "скидка" или "компания", а просто - value?
Дальше, по этой логике, можно добавить поля "table" и "field".
То есть логировать не действия пользователя, а изменения таблиц (пользователем).

Гм. правда, при удалении строки придётся писать в old_value весь набор полей удалённой строки. Или делать 10 записей (для каждого поля отдельно)...

 

[rotoZOOM]

Глобальная задача: протоколировать ВСЕ действия привилегированных пользователей. Поменял ли пользователь скидку своего товара, изменил цену, добавил категорию, удалил фотографии, назначил другую главную фотографию и т.д.
Если реализовать все и сразу - это действительно получится 100500 вариантов, тем более, что я знаю, что в итоге все равно обкатывая систему, желания заказчика устаканятся на паре десятков фильтров.
Поэтому я и не хочу реализовывать все и сразу, но разработать такую архитектуру, которая бы позволила гибко расширять возможности логирования/фильтрации без необходимости коренным образом менять систему журналирования.

 

[KorP]

а данные где? какие у тебя там кучи фирм/товаров

протоколировать ВСЕ действия

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

 

[rotoZOOM]

не вижу смысла в фильтрах по "значению"

Это требование заказчика.

Городской мебельный портал, но не интернет-магазин.
Пользователи - админы, компании (владельцы компаний), контент-менеджеры.
У всех этих товарищей есть доступ к контенту. Владельцы магазинов могут менять свой список товаров, атрибуты товаров, свойство своих магазинов (редактировать адреса, логотипы), всяческие спецразмещения товаров в зависимости от типов товарных групп и т.д.
Контент-менеджеры пишут статьи, SEO-наполнение страниц.
Админы могут все.

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

 

[rotoZOOM]

Смысл этого, в том числе и в постмодерации. Админ смотрит чего там магазины наизменяли, что-то правит, где-то выносит предупреждения и т.д.

 

[KorP]

а теперь считаем, по твоим словам у тебя 100-200 действий, а сколько будет значений? в 10 раз больше? как ты это будешь выводить пользователю? выпадающей менюшкой? и как можно выбрать то, чего человек не знает (какая была скидка, например, или какой она стала, или на какое название сменили старое? чушь полнейшая)
если у тебя привязка по производителям/товарам - добавляй их id и всё, будет в таблице поле для компании или товара. я по тому и просил напистаь подробно, что бы можно было продумать структуру

 

[Breeze]

Сделай словари:
изменил, добавил, удалил, назначил, прилепил
фотографию, цену, товар, категорию, фамилию

в основную таблицу пиши: ид, юзер, словарь1(действие), словарь2(над чем поглумился), комментарий, дата
таблица с данными основной: ид, ид_основной, тип(с,в,на,к), значение

и делай хоть 100500 отчетов, по словарю2 можешь выбирать шаблон вывода

 

[rotoZOOM]

выпадающей менюшкой?

Мне явно не понадобится выводить абсолютно все значения. Но у меня должна быть возможность создать фильтр по любому параметру, выбранному заказчиком (например, "нужен фильтр по переносу пользователя в определенную группу").
И да, что не так с выпадающей менюшкой?

Breeze, значение во второй таблице - это я так понял опять таки разноплановая величина? Может быть числом, может быть списком?

 

[KorP]

(например, "нужен фильтр по переносу пользователя в определенную группу")

какую группу? если значение "системное" - создавай справочник. а если значение, задаваемое пользователем, как кому то может прийти в голову искать то, о существовании чего он даже не подозревает?
я полностью согласен с Breeze, нужно всё добавлять в справочники, всё что можно (кроме пользовательских значений естественно, ибо их мы не знаем и не можем знать, соответственно и не можем по ним фильтровать ничего, только как поиск по строке) и дробить эти справочники как можно сильнее для большего удобства поиска

 

[Breeze]

значение во второй таблице - это я так понял опять таки разноплановая величина? Может быть числом, может быть списком?

типа того, если хочешь универсальности, придется дробить.
в итоге получишь 1С