Стратегии ведения журнала аудита
-
03-07-2019 - |
Вопрос
Я пытаюсь выбрать наилучший метод ведения журнала аудита в моем приложении.Основной причиной создания журнала является сообщение о последовательности событий (изменений).
У меня есть иерархия объектов, мне нужно создавать отчеты, когда что-то меняется в любой части этой иерархии, позднее.
Я думаю, что у меня есть три варианта:
- Заведите журнал для каждой таблицы и, следовательно, сопоставьте иерархию объектов, а затем создайте представление для отчета.
- Сгладьте иерархию и отмените нормализацию таблицы, упростив составление отчетов - простая инструкция select.
- Имейте одну таблицу журнала и запись для каждого изменения, что усложняет составление отчетов, но делает их более гибкими к изменениям.
В настоящее время я склоняюсь к варианту 1.
Решение
Журнал аудита - это, в основном, хронологический список событий, которые произошли, кто выполнил эти события и что это были за события. Р>
Я думаю, что плоский вид будет лучше, так как его легко заказать и запросить. Поэтому я больше склоняюсь к вашему варианту № 2 / № 3. Р>
Включите такие вещи, как тип транзакции, время, идентификатор пользователя, описание того, что изменилось, и другую соответствующую информацию, связанную с вашим продуктом. Р>
Вы также можете со временем добавлять вещи в свой продукт, и вам не нужно будет постоянно изменять модуль журнала аудита. Р>
Другие советы
Я должен поговорить на эту тему, даже несмотря на то, что она старая.
Обычно иметь только одну таблицу аудита - плохая идея, поскольку вы создадите проблемы с блокировкой в базе данных, когда все попадет в эту таблицу.Используйте отдельные таблицы аудита для каждой таблицы.
Это также плохая идея - поручать приложению проводить аудит.Аудит должен проводиться на уровне базы данных, иначе вы рискуете потерять часть информации.Данные изменяются не только из приложений в большинстве баз данных;никто не собирается менять цены на все свои продукты по очереди в пользовательском интерфейсе, когда вам нужно увеличить их на 10% для всех 10 000 000 из них.Аудит должен фиксировать все изменения, а не только некоторые из них.Это должно быть сделано в триггере в большинстве баз данных (SQL server 2008 имеет встроенную функцию аудита).Некоторые из наихудших потенциальных изменений (сотрудники, совершающие мошенничество или желающие злонамеренно уничтожить данные) также часто происходят не из приложения, а из других мест, особенно если вы предоставляете пользователям доступ на уровне таблиц (чего вы не должны делать ни в одной финансовой базе данных или в той, которая содержит личную информацию).Аудит из приложения этого не обнаружит.Разработчики часто забывают, что при защите своих данных внешние источники являются не единственной угрозой.
Если бы это было для целей аудита, я бы использовал истинный носитель только для добавления, а не таблицу / таблицы в той же базе данных.
Вы предлагаете это для целей истории изменений - в этом случае я бы реструктурировал ваше приложение / db для записи реальных событий, а не только текущего состояния.
Я бы пошел с (2) и (3): создать единую таблицу для всех записей аудита.
Плоский вид хорош при условии, что дополнительное выравнивание не влияет на производительность.
Вы можете обратиться к AOP-фреймворку, чтобы помочь с этим. Это позволит вам добавить функциональность регистрации в начало или конец любого / всех методов. Если вы пойдете по этому пути, это может помочь определить, что имеет смысл для хранения данных журнала.