Какова лучшая практика для реализации пересмотра базы данных? - PullRequest
2 голосов
/ 03 марта 2011

Какова лучшая практика для реализации пересмотра базы данных?

Предположим, у меня есть таблица с именем Test и еще одна таблица для проверки с именем Test_Rev.

Предполагается, что я буду отслеживать изменения записей Test в таблице Test_Rev.

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

Я создал отдельный поток, используя шаблон Producer-Consumer, а затем передал сущности, которые мне нужны для ревизии, этому потоку.

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

Это хорошо работает, но мне нужно знать лучшие практики.

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

Кстати, я использую VS 2010, SQL Server 2005, Entity Framework

Ответы [ 2 ]

1 голос
/ 03 марта 2011

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

1 голос
/ 03 марта 2011

Зависит от того, довольны ли вы логикой в ​​базе данных.Если у вас нет проблем с этим, используйте триггеры БД.Если вы хотите сохранить логику в приложении, переопределите SaveChanges в производном ObjectContext и запустите пересмотр (добавление сущностей редакции) перед выполнением base.SaveChanges.Единственной проблемой может быть «аудит» вновь добавленных объектов с автоматически сгенерированным ключом - ключ известен только после вызова base.SaveChanges.Поэтому в таком случае вы должны проверять добавленные сущности после сохранения изменений и снова вызывать base.SaveChanges.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...