Какие посоветуете средства аудита изменений данных в MSSQL?

Question

[Coper]

Какие посоветуете средства для аудита изменений данных в MSSQL (нужно сохранять изменение всех полей), где связка mssql + NHibernate.

Из того что нашёл, это:

1. Повесить на тригеры в базу данных запись истории в таблицы с историей.

2. В самом NHibernate повесить обработчики в Interceptors или EventListeners и писать в таблицы с историей.

3. Использовать фичу 2008 MSSQL — Change Data Capture. Тут вопрос, стоит ли её для этого использовать, где-то читал «Основной сценарий, в котором предполагается использовать CDC — это „большие“ ETL (extraction, transformation, loading) приложения, которые асинхронно кусками перегоняют данные из OLTP системы в хранилище данных.»

Может есть готовые простые решения.

Answer 1

[Flanker72]

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

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

Вот пример обсуждения темпоральности (хронологии изменений) касательно именно MSSQL. Думаю, тема может быть полезной.

Answer 2

[noRerih]

На .NET/Java никогда не разрабатывал, но в одной умной книжке недавно увидел рекомендацию использовать DbDeploy, однако не знаю насколько это поможет решить Вашу задачу.

Answer 3

[Арександр]

зависит от нагрузки, если данных и изменений очень много и критично быстродействие, то только 3-й вариант CDC - может работать без нагрузки на основную БД (на выделенном сервере), однако требует MS-SQL Enterprise Edition
дополнительно посмотрите проект AutoAudit на codeplex - возможно вам подойдет.
разница между 1,3 и 2 вариантом, в том, что 1и3 вы будете видеть историю на физическом уровне БД (таблицы БД), во 2-ом на логическом уровне прикладных C# Объектов. Однако логировать придется либо на клиенте, либо на сервере приложений - может стать критично к памяти по количеству обрабатываемых записей (если в транзакции более 10тысяч изменений). Опять же если у вас в БД есть хранимые процедуры, то во 2-ом варианте вы упустите из аудите их изменения