Внедрение аудита - Spring AOP vs .Hibernate Interceptor vs DB Trigger

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

Итак, вот мой вопрос...

Мне нужно выполнить ревизию изменений в базе данных - вставить \updates\delete в бизнес-объекты.

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

1) Триггеры DB

2) Перехватчики спящего режима

3) Spring АОП

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

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

Я не прошу подробности о реализации. Это обсуждение дизайна.

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

Ответ 1

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

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

Триггеры DB

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

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

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

Ответ 2

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

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

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

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

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

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

Ответ 3

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

Ответ 4

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

Ответ 5

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

Ответ 6

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