NHibernate: Аудит журнала с использованием перехватчика или триггеров?

Question

Триггеры кажутся простым решением для ведения журнала аудита. Почему я должен использовать перехватчики?

1. Переносимость базы данных - это один из триггеров ...

Кто другие?

Answer 1

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

Answer 2

Я согласен с HLGEM. Хорошей альтернативой преимуществам наличия как триггеров, так и переносимости СУБД является использование некоторого инструмента аудита, который: С учетом плана аудита: сгенерировать триггеры для соответствующей СУБД

Пабло Хавьер

Answer 3

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

1. Чтобы не привязывать себя к конкретной базе данных. портирование на разные СУБД значительно проще.

2. Чтобы модель вашего домена не проникала в другие области вашего кода. т.е. база данных должна знать, изменилась ли запись.

Но все это зависит от контекста. Если жизненно важно, чтобы все изменения в определенных записях были необходимы, то я думаю, что HLGEM верен. триггеры являются лучшими для обработки этого типа senario.

Answer 4

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

Я считаю, что база данных - это просто область сохранения приложения. Из одного приложения. Другими словами, я не думаю, что другие системы должны использовать мою базу данных напрямую, и поэтому я думаю, что аудит должен проводиться вне базы данных (т.е. не с триггерами).

Answer 5

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

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

Плюс, не нужно больше неаккуратного кода T-SQL ...