Плюсы и минусы событий базы данных

Question

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

Answer 1

Определенно используйте метод асинхронного ввода. Если вы находитесь на SQL платформе Microsoft проверить комбинацию

1) Отслеживание изменений доступен SQL Version> 2008: http://msdn.microsoft.com/en-us/library/cc280462.aspx

и

2) SQL Service Broker, который вы можете зарегистрироваться для событий с , (1. на самом деле использует 2. под капотом IIRC): http://msdn.microsoft.com/en-us/library/ms345108(SQL.90).aspx

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

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

НТН Alex

Answer 2

Похоже, вы планируете реагировать на события базы данных в своей бизнес-логике. Если это так, это будет очень плохая идея, игнорируя почти все, что обычно считается хорошим дизайном программного обеспечения (Layering, Разделение проблем и т. Д.).