Лучший подход к запуску события в базе данных SQL

Question

Проще говоря, у меня есть база данных SQL с внешним интерфейсом .net, и мне нужно отключить события, когда достигается определенное время.Я называю их будильниками, чтобы пользователь мог установить будильник, скажем, в 12:30 в х день, а когда наступит это время в х день, появится всплывающее окно с напоминанием.

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

Любое понимание = отлично

Да, извините, вызывает у меня в голове какой-то другой проект (недостаток сна).

Чтобы уточнить, может быть подключено несколько клиентов (обычно 2 всегда будут включены, но может случиться так, что все отключится и ни один не будет подключен). Поэтому мне нужно будет подумать о том, как происходят аварийные сигналы / всплывающие окна.,Когда они получают всплывающую тревогу, они могут отклонить ее или «выполнить действие», чтобы сказать, что выполнили задание.

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

Спасибо за все комментарии: Похоже, я хочу центральную программу или службу ?.

У меня может быть служба, которая продолжает опрашивать базу данных, проверяя время будильника и текущих активных пользователей, если найдет, она обновляет таблицу уведомлений, которую пользователь опрашивает страницы каждые несколько секунд (10) (Уточнение: время будильника), должны быть заблаговременно заблаговременно, и тревожное уведомление не обязательно должно быть с точностью до секунд).Как это звучит?.

С точки зрения нагрузки, я не вижу более 15-20, использующих его за один раз, но обычно только около 5-6.

Есть какие-либо явно очевидные упущения или проблемы ?.

Answer 1

Не думаю, что вы правильно понимаете триггеры. Они запускаются в зависимости от предпринятых действий (например, строка вставляется в таблицу). Они не основаны на времени. Я не думаю, что это то, что вы ищете, основываясь на вашем объяснении.

Кто будет видеть эти сигналы тревоги? Будут ли они буквально всплывающими окнами на клиентском компьютере? Если в лесу появляется всплывающее окно, и никто не читает его, был ли еще сигнал тревоги?

Мое первое, хотя, учитывая ограниченную информацию, было бы, чтобы клиент загружал любые данные тревоги при первом ее открытии. Если какие-либо тревоги пропущены (то есть они должны были сработать, когда человек не вошел в систему), они сразу же всплыли бы (желательно с некоторым визуальным признаком того, что они были в прошлом). Любые другие тревоги, которые запланированы в ближайшем будущем, могут затем быть настроены на отключение в соответствующее время.

Приложение может периодически перезагружать сервер (раз в минуту, раз в 10 минут), чтобы узнать, не установлены ли в системе новые аварийные сигналы. Недостатком здесь является то, что, если кто-то входит и создает сигнал тревоги в ближайшее время, он может не появиться до следующего опроса базы данных. Это поможет вам определить бизнес-правила относительно того, как часто нужно проводить опрос.

Некоторые дополнительные замечания об этом подходе ... вам нужно пометить тревоги как «обработанные», чтобы они не появлялись снова. Также вам необходимо убедиться, что часы клиентов синхронизированы с сервером. Кроме того, вам нужно учитывать различные часовые пояса?

Другой возможный подход заключается в том, чтобы иметь центральный сервер, который опрашивает базу данных и выдает сигналы тревоги клиентам. Это может избавить каждого клиента от необходимости постоянно опрашивать базу данных (у вас есть только один опрашивающий), но он не будет ловить «пропущенные» тревоги. Если у вас всегда есть куча клиентов, которым нужно отправлять оповещения «по всему миру», это может быть маршрут Если сигналы тревоги зависят от пользователя, я бы выбрал первый подход.

Answer 2

Триггеры активируются, когда что-то происходит в базе данных.

В прошлом я использовал все следующее ...

1.Использование внешнего приложения

Если есть приложение, которое должно знать о событии, укажите время события в приложении.

Если имеется несколько клиентов, вам необходимокоординировать их.Либо с центральным главным приложением, либо с некоторым процессом синхронизации.

2.Агенты

MS SQL Server имеет возможность устанавливать время и повторять события, которые запускают некоторый SQL.

Это полезно, если нет внешнего клиентского приложения, которое нуждается в этомсобытие, которое должно быть запущено.

Если у вас несколько клиентских приложений, это похоже на вариант 1, но SQL Server становится центральным приложением, и клиенты опрашивают сервер, чтобы узнать, что происходит.

3.Бесконечный цикл

Вместо (или вместе с ними) агентов можно написать бесконечный цикл и использовать команды типа WAIT для приостановки до следующего события.

ПРИМЕЧАНИЕ

Что лучше всего зависит от того, что вы на самом деле собираетесь делать с этими событиями.Опрос не является проблемой, но, как правило, лучше иметь единую точку, управляющую срабатыванием событий.

Обратите внимание, вы (обычно) не хотите иметь соединения от клиента к стоящему SQL Server.открыть навсегда.И вы не можете открыть форму подключения SQL Server к группе клиентских приложений.Таким образом, приложения должны будут опрашивать сервер независимо.Но вы можете быть умным об опросе.

Answer 3

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

РЕДАКТИРОВАТЬ:

Также есть отличная команда SQL waitfor , если вы хотите отложить выполнение чего-либо в будущем