Стратегии ведения журнала аудита

Question

Я пытаюсь выбрать лучший способ ведения журнала аудита в моем приложении. Основной причиной журнала является сообщение о последовательности событий (изменений).

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

Я думаю, что у меня есть три варианта:

1. Иметь журнал для каждой таблицы и, следовательно, соответствовать иерархии объектов, а затем создавать представление для отчета.
2. Выровняйте иерархию и отмените нормализацию таблицы, упрощая отчетность - просто оператор select.
3. Наличие одной таблицы журнала и записи для каждого изменения, что усложняет отчетность, но делает ее более гибкой.

В настоящее время я склоняюсь к варианту 1.

Answer 1

Мне нужно поговорить на эту тему, хотя она старая.

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

Также плохая идея, чтобы приложение выполняло аудит. Аудит должен проводиться на уровне базы данных, иначе вы рискуете потерять часть информации. Данные не меняются только от приложений в большинстве баз данных; никто не собирается менять цены на все свои продукты по одному из пользовательского интерфейса, когда вам нужно 10% -ное увеличение на все 10 000 000 из них. Аудит должен фиксировать все изменения, а не только некоторые из них. Это должно быть сделано в триггере в большинстве баз данных (SQL Server 2008 имеет встроенную функцию аудита). Некоторые из наихудших возможных изменений (сотрудники, совершающие мошенничество или желающие злонамеренно уничтожить данные), также часто происходят не из приложения, а из других мест, особенно если вы разрешаете пользователям доступ на уровне таблицы (чего не следует делать ни в одной финансовой базе данных или в базе данных, содержащей Персональные данные). Аудит из приложения не поймает это. Разработчики часто забывают, что при защите своих данных внешние источники - не единственная угроза.

Answer 2

Журнал аудита - это, в основном, хронологический список событий, которые произошли, кто выполнил эти события и что это были за события.

Я думаю, что плоский вид будет лучше, так как его легко заказать и запросить. Поэтому я больше склоняюсь к вашему варианту № 2 / № 3.

Включите такие вещи, как тип транзакции, время, идентификатор пользователя, описание того, что изменилось, и другую соответствующую информацию, связанную с вашим продуктом.

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

Answer 3

Если бы это было для целей аудита, я бы использовал настоящий носитель только для добавления, а не таблицу / таблицы в той же базе данных.

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

Answer 4

Я бы пошел с (2) и (3): создать единую таблицу для всех записей аудита.

Плоский вид хорош при условии, что дополнительное выравнивание не влияет на производительность.

Answer 5

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