Является ли EF или SQL лучшим выбором для аудита изменений данных?

Question

Требование кажется простым: когда данные изменяются, проверяйте изменения.

Вот несколько важных частей уравнения:

1. Данные в моем приложенииохватывает несколько таблиц (некоторые перекрестные ссылки. таблицы).
2. Мой DTO глубокий, с условно заполненными свойствами навигации.
3. При загрузке я копирую исходный DTO с его «исходными значениями».
4. Когда запрашивается сохранение,исходный DTO содержит изменения.
5. В идеале внешние ключи должны читаться как полезный текст, а не как номера идентификатора.

В отличие от функции классной истории TFS, моя кажется более сложной из-за множества связанных таблиц и условных дочерних объектов.

Я вижу три возможности (пока):

1. Я мог бы использовать C # для отражения объектов и создания записи до / после.
2. Я мог бы использовать триггеры в SQL 2008R2, чтобы перехватывать изменения и объединять запись до / после.
3. Я мог бы хранить необработанные объекты до / после и позволить SQL 2008R2 их анализировать.

Обратите внимание: сейчас мне кажется, что CDC в SQL 2008R2 слишком тяжелыйварианта.Я действительно ищу что-то, что я могу построить, но я признаю, что мой разум сейчас открыт для всего.

Мой вопрос

Прежде чем я начну строить это: Как все остальные справляются с проверкой сложного EF DTO?

Есть ли доступное низко-технологическое решение?

Заранее спасибо.

Связанные, но не полностью связанные вопросы, уже в StackOverflow: Реализация журнала аудита / истории изменений с помощью MVC & Entity Framework и Создание аудита данных в SQL Server и https://stackoverflow.com/questions/5773419/how-to-audit-many-to-many-relationship-in-entity-framework и Ведение журнала аудита для сущностей, разбитых по нескольким таблицам и Linq to SQL Audit Trail / Audit Log: использовать триггеры или doddleaudit? не предоставляютответить.

Answer 1

ЕСЛИ аудит является реальным требованием, я бы выбрал триггерное решение ... так как другие методы имеют несколько "недостатков":

• "слепые" к любым изменениям, происходящим с помощью других средств, кроме вашегоприложение
• если вы внесете некоторые изменения в код и забудете о добавлении кода аудита, журнал аудита получит «мертвые зоны»

Решение на основе триггера может быть защищено, так что только специальные пользователиЯ даже могу видеть проверенные данные ...

Я обычно работаю с Oracle, но из своего опыта в таких ситуациях: разрешить приложению только ВЫБРАТЬ права с помощью Views, любая вставка / удаление / обновление должна выполняться с помощью хранимых процедур иконтрольный журнал должен выполняться через триггеры ...

Answer 2

Ну, посмотрим. Аудит SQL Server уже существует, поставляется с инструментами, вероятно, уже известен вашим администраторам баз данных, не замедляет работу вашего приложения и может отслеживать события, которые само приложение никогда даже не увидит .

С другой стороны, сворачивание собственного в EF позволит вам проводить аудит источников данных, отличных от SQL Server. Это также не требует EE.

Answer 3

Недавно я внедрил менеджер журналов аудита поверх Entity Framework.Когда я создаю экземпляр моего менеджера по аудиту, я отражаю все классы сущностей и сохраняю информацию о свойствах.Затем в контексте объекта SavingChanges я проверяю все изменения.Работает отлично.В случае внешних ключей я просто сохраняю их идентификаторы до и после изменений.

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

Answer 4

Trigger Solution, Плюсы:

1. Невозможно обойти аудит

Триггерное решение, Минусы:

1. Невозможно провести аудит не данных SQL
2. Невозможно проверить сложные объекты при вставке

Entity Framework, Плюсы:

1. Может проверять все
2. Может проверять сложные объекты в любом состоянии

Entity Framework, Минусы:

1. Может быть обойдено (как direct-to-SQL)
2. Требуется копия оригинальных значений

Мой выбор - Entity Framework. Использование STE делает это проще.

В любом случае вы должны свернуть свои собственные.