Реализация аудита - Spring AOP против перехватчика Hibernate против триггера БД

Question

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

Так вот мой вопрос ...

Мне нужно проверять изменения БД - вставлять \ обновлять \ удалять в бизнес-объекты.

Я могу придумать три способа сделать это

1) Триггеры БД

2) Перехватчики гибернации

3) Пружина AOP

(Этот вопрос относится только к Spring \ Hibernate \ RDBMS - я думаю, это нейтрально для java \ c # или hibernate \ nhibernate - но если ваш ответ зависит от C ++ или Java или конкретной реализации hibernate - уточните, пожалуйста)

Каковы плюсы и минусы выбора одной из этих стратегий?

Я не спрашиваю о деталях реализации. Это обсуждение проекта.

Я надеюсь, что мы сможем сделать это как часть вики сообщества

Answer 1

Я могу говорить только о триггерах и NHibernate, потому что я не знаю достаточно о весне AOP.

Как всегда, это зависит от того, что для вас важнее.

Триггеры БД

• быстр
• всегда вызывается, даже из собственного SQL, скриптов, внешних приложений.
• записать в БД данные, о которых NH не знает. Это будет отсутствовать в текущем сеансе. (Что может привести к неожиданным результатам)
• обычно ничего не знают о вашем сеансе (скажем: логин).

Перехватчики / события NHibernate

• не являются специфичными для СУБД.
• позволяет вам легко получить доступ к вашей деловой информации, такой как сеанс пользователя, имя клиентского компьютера, определенные вычисления или интерпретации, локализация и т. Д.
• позволяет вам декларативную конфигурацию, например атрибуты объекта, которые определяют, нужно ли регистрировать объект и как.
• позволяет отключить ведение журнала, это может быть важно для обновлений, импорта, специальных действий, которые не запускаются пользователем.
• позволяет вам просматривать сущность бизнес-модели. Вы, вероятно, ближе к точке зрения пользователей.

Answer 2

Я понимаю, что это не на 100% связано с вопросом, но добавляет новых возможностей.

Есть еще два способа проверить, что происходит.

Чтение журнала транзакций: если база данных находится в режиме полного восстановления, все подробности об операторах INSERT, UPDATE, DELETE и DDL регистрируются в журнале транзакций.

Проблема в том, что его очень сложно читать, потому что он не поддерживается изначально, и вам потребуется стороннее средство чтения журналов транзакций, такое как ApexSQL Log или SQL Log Rescue ( Последний является бесплатным, но поддерживает только SQL 2000).

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

Трассировки SQL Server: Трассировки будут захватывать все в файлах трассировки, включая операторы select, которые также могут понадобиться для некоторых сценариев соответствия. Недостатком является то, что трассировки представляют собой текстовые файлы, которые необходимо проанализировать и упорядочить.

Answer 3

Я не могу придумать вескую причину не использовать триггеры базы данных для аудита изменений в базе данных. Вставки, обновления и удаления могут поразить базу данных из разных источников - триггеры поймают все это; Спящий и т. Д. Не будет.

Answer 4

старый вопрос, с которым я столкнулся сейчас. Доступен еще один вариант - Envers, который доступен вместе с hibernate начиная с версии 3.6 и далее.

Answer 5

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

Answer 6

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