Структура модуля логов

[arogachev]

Разрабатываю модуль логов (пока только по ActiveRecord, будут также и произвольные сообщения).

На данный момент набросал следующую структуру в миграции:

http://pastebin.com/3LNUBMKM

В log_models добавляются логируемые модели, в log_attributes - соответственно список атрибутов для каждой модели.
log_models_changes отражает изменения модели, log_attributes_changes - соответственно каждого отдельно взятого атрибута.
log_list_attributes-changes - для атрибутов many-to-many (чтобы они не просто склеивались каким-то разделителем, а можно было извлечь и отформатировать как угодно).

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

P.S. null в добавлении ключей - это используются переопределенные методы, которые автоматически генерируют название, основываясь на конвенции.

[arogachev]

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

[zelenin]

https://github.com/zelenin/yii2-request-log-module создал модуль логов реквестов. Потом планирую модуль изменений моделей. В принципе это простая разработка, и не вижу смысла в совместной разработке (работы на 4-8 часов).

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

[arogachev]

Да, добавление и редактирование будет из админки. Но поведение тоже будет вешаться для кое-какой кастомизации, если быть точнее - для записи преобразованных (читаемых) значений атрибутов. А возможно, настройка будет делаться через конфиг модуля, пока не решил.

[maleks]

arogachev, а что там точно за функционал планируется?

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

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

[zelenin]

arogachev, а что там точно за функционал планируется?

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

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

история изменений объектов AR

[S c]

как по мне - эти две вещи вообще разделить нужно.

[zelenin]

как по мне - эти две вещи вообще разделить нужно.

какие эти две?

[maleks]

история изменений объектов AR

вот такое абсолютно неинтересно.
Типично - придумывают себе легенькие задачки, оторванные от практики, лишь бы запулить расширение.

[zelenin]

история изменений объектов AR

вот такое абсолютно неинтересно.
Типично - придумывают себе легенькие задачки, оторванные от практики, лишь бы запулить расширение.

тут вижу одну вещь. о каких двух вещах речь?)
насчет практики вы не правы. Как история изменений может быть неважной вещью?

[maleks]

как по мне - эти две вещи вообще разделить нужно.

по идее если делать логи на сайте то это должны быть одни логи.
А не - вот тут какие то логи для кодера.
А вон там логи для администратора.

Например страницу со списком не найденных страниц полезно видеть и админу чтобы увидеть битые ссылки и настроить редиректы.
А не какие то специфические логи по моделям доступные для пользования только кодером.

[zelenin]

как по мне - эти две вещи вообще разделить нужно.

по идее если делать логи на сайте то это должны быть одни логи.
А не - вот тут какие то логи для кодера.
А вон там логи для администратора.

Например страницу со списком не найденных страниц полезно видеть и админу чтобы увидеть битые ссылки и настроить редиректы.
А не какие то специфические логи по моделям доступные для пользования только кодером.

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

[maleks]

насчет практики вы не правы. Как история изменений может быть неважной вещью?

может она где то и будет нужна.
Но это и должно тогда называться - история изменения чего то.
А не лог. (Структура модуля логов)

[maleks]

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

вон ТС пишет:

Разрабатываю модуль логов (пока только по ActiveRecord, будут также и произвольные сообщения).

[zelenin]

насчет практики вы не правы. Как история изменений может быть неважной вещью?

может она где то и будет нужна.

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

Но это и должно тогда называться - история изменения чего то.
А не лог. (Структура модуля логов)

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

[zelenin]

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

вон ТС пишет:

Разрабатываю модуль логов (пока только по ActiveRecord, будут также и произвольные сообщения).

ну хз, что он имеет в виду. Пока тут об AR

[S c]

как по мне - эти две вещи вообще разделить нужно.

какие эти две?

"ошибки, логи доступа и тд" и "история изменений объектов AR"

[zelenin]

как по мне - эти две вещи вообще разделить нужно.

какие эти две?

"ошибки, логи доступа и тд" и "история изменений объектов AR"

да, конечно. Это должны быть разные логи.

[arogachev]

maleks, возможно я не до конца объяснил.

Логи, которые вы описали, планируются к реализации тоже (в рамках одного модуля даже скорее всего). Я об этом вкратце упомянул. Смешивать с историей изменений моделей их, на мой взгляд, нецелесообразно.

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

Пользователь Иван Иванов (ivanov@mail.ru) изменил пост "Yii2 SEO" (здесь ссылка для перехода), изменен контент, показан дифф контента (для текстовых полей).
Для many-many допустим: к списку городов добавлен "Санкт-Петербург".
Т.е. в читабельном виде.

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

[arogachev]

Я все же попробую реализовать описанный подход. Буду рад советам и предложениям.