Единая централизованная или отдельная таблица журналов для модулей?

Asked
Viewd320

3

Я разрабатываю интранет-систему для среднего бизнеса. Должен ли я вести единую таблицу журналов для всех модулей или сделать ее отдельной?

В журнале аудита хранятся все действия администратора / персонала (создание, обновление, удаление объектов), а структура журнала универсальна для любого типа модуля.

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

Как лучше всего сообщать о таких случаях?

4 ответов

2

Что ж, когда вы идете просматривать свои журналы, что вы бы предпочли, посмотрите в одном месте, где вы можете увидеть все, или вам нужно проверить несколько разных мест, каждое из которых показывает только одну часть системы изолированно?

Имейте в виду, что с помощью единственной таблицы легко отфильтровать записи, которые не имеют отношения к делу или которые пользователь не имеет прав для просмотра. Объединение нескольких отдельных журналов в единое всеобъемлющее представление немного сложнее, к тому же оно имеет дополнительный недостаток, заключающийся в том, что в большинстве проектов требуется пересматривать код, который выполняет объединение каждый раз, когда добавляется новая таблица журналов. p>

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

3

См. log4php . log4j решил большую часть проблем с ведением журнала, введя иерархию и уровни журналов. Я не знаю, насколько хорош log4php, но он должен быть стартером.

1

Мы используем единую таблицу, и это оказалось лучшим решением, особенно по производительности. И особенно с большими наборами данных. Если вас интересует готовое решение - попробуйте это .

3

Я бы сказал, один стол.

Возможно, вы захотите узнать активность пользователей, например, во всех модулях (если я правильно понимаю). Что поддается одному столу.

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

Наконец, я бы явно сохранил имя и тип объекта (объекты базы данных). Если вы DROP и CREATE, то ID изменится. Или таблица может стать, например, представлением, поэтому изменится и ее тип, и объект.