Блог

В базе данных SQL Server 2012 мы хотим создать журнал аудита почти для всех основных таблиц при операциях обновления и удаления.Обычно мы создаем журнал аудита с использованием триггера для каждой таблицы и сохраняем его в теневой таблице. Итак, есть какое-либо влияние на производительность? если в любой таблице обновлены или удалены огромные записи. Есть ли другой способ реализовать журнал аудита?

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

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

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