Реализация контрольного журнала: Spring AOP, Hibernate Interceptor и DB Trigger

Question

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

Вот мой вопрос...

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

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

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

2) Спящие перехватчики

3) Пружинный АОП

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

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

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

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

Answer 1

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

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

Триггеры БД

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

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

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

Answer 2

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

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

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

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

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

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

Answer 3

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

Answer 4

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

Answer 5

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

Answer 6

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