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

Question

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

Answer 1

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

1) Отслеживание изменений доступно Версия SQL> 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

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