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

Question

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

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

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

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

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

Answer 1

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

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

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

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

Answer 2

Я должен поговорить на эту тему, даже несмотря на то, что она старая.

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

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

Answer 3

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

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

Answer 4

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

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

Answer 5

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