Единая централизованная или отдельная таблица журналов для модулей?
Вопрос
Я разрабатываю интранет-систему для среднего бизнеса.Должен ли я вести единую таблицу журнала для всех модулей или сделать ее отдельной?
Журнал аудита хранит все действия администратора / персонала (создание, обновление, удаление объектов), а структура журнала универсальна для любого типа модуля.
А также, хорошая ли это идея, если я создам отчет на основе записей журнала?Моя таблица журнала хранит тип объекта и идентификатор объекта, чтобы я мог извлекать данные для любого объекта и в любое время на основе события, имени объекта и идентификатора объекта.
Каков наилучший подход к отчетности в таких случаях?
Решение
Хорошо, когда вы отправляетесь просматривать свои журналы, что бы вы предпочли сделать, посмотреть в одном месте, где вы можете увидеть все, или вам придется проверить несколько разных мест, каждое из которых просто показывает одну часть системы изолированно?
Имейте в виду, что с помощью одной таблицы тривиально отфильтровать записи, которые не имеют отношения к делу или на просмотр которых у пользователя нет разрешения.Объединение нескольких отдельных журналов в единое всеобъемлющее представление немного сложнее, плюс у него есть дополнительный недостаток, заключающийся в том, что в большинстве проектов требуется повторно просматривать код, который выполняет объединение каждый раз, когда добавляется новая таблица журналов.
Я определенно говорю, что предпочтительнее использовать один журнал.Единственная ситуация, о которой я могу думать, где было бы уместно несколько отдельных журналов, была бы, если бы соображения безопасности были достаточно сильны, чтобы требовать, чтобы записи журнала с разной видимостью были физически разделены - и в таком случае вы, вероятно, смотрели бы на отдельные серверы журналов, а не только на отдельные таблицы.
Другие советы
Видишь log4php. log4j ( лог4j ) решена большая часть проблем ведения журнала за счет введения иерархии журналов и уровней.Я не знаю, насколько хорош log4php, но это должно быть началом.
Я бы сказал, один стол.
Например, вы можете захотеть найти активность пользователей во всех модулях (если я правильно понимаю).Который подходит для одной таблицы.
Отчитываться по вашей таблице журналов было бы нормально.Вы выполняете выгрузку в отдельную базу данных отчетов, чтобы уменьшить конфликты и нагрузку на таблицу ведения журнала.
Наконец, я бы сохранил имя и тип объекта явно (объекты базы данных).Если вы ОТБРОСИТЕ и СОЗДАДИТЕ, то идентификатор изменится.Или таблица может стать представлением, например, так что изменится и ее тип, и идентификатор объекта.
Мы используем single table, и это оказалось лучшим решением, особенно с точки зрения производительности.И особенно с большими наборами данных.Если вас интересует готовое решение - попробуйте это.