Добрый вечер!
В свете назревшей необходимости организации уведомления пользователей об изменениях в БД пришлось задуматься о реализации такого механизма в приложении. Исходник получается такой: есть порядка десятка событий, о которых нужно уведомлять приложение, и около 20 пользователей, которым эти уведомления могут быть нужны. Причем, одно и то же событие в разные моменты может быть актуальным для разного числа пользователей (бизнес-логика). Выходит 2 варианта:
1. По факту наступления события генерить POST_EVENT 'DB_EVENT34' (для условного 34 события), ловить все это на клиенте, дергать что-то на сервере, чтобы определиться, есть ли на самом деле что-то новое.
2. По факту события генерить POST_EVENT 'DB_EVENT34_USER18' (событие 34 для пользователя 18) для каждого пользователя, которого касается изменение.

Минус 1 варианта:
- дополнительное "холостое" дерганье базы всеми клиентами по наступлению каждого вида события.

Минус 2 варианта:
- одномоментно генерится приличное (20) количество событий.

Второй вариант кажется более гуманным и адресным, но, может, я чего-то не учел?

P.S. Ожидаемая средняя интенсивность наступления событий - в пределах 50 в час.

Дополнение:
- здешние темы про события пролистал, но эту сторону вопроса особенно обсужденной не заметил.
- клиентская сторона на FiB.

Dimitry SibiryakovЕсли какому-то пользователю не нужно уведомление о каком-то событии, он может на него и не
подписываться.Собственно, и рассылать уведомления о событиях я планировал во втором варианте по списку, лежащему в таблице. Дело в том, что два последовательных однотипных (по источнику происхождения) события не обязательно должны касаться оба одного и того же пользователя, как, например, корректировка в БД двух документов с уведомлением пользователя-автора (создателя) о событии (когда автор у документов разный).

Уточню вопрос:
Не будет ли "грузить" сервер потенциально возможный выстрел из 20 post_event с разными текстами в короткой транзакции из 5 секунд?

NikolayV81Самый простой способ проверит - попробовать, но 4/сек. как то совсем несерьёзное количество, другое дело что если на ваши 20 одновременных событий клиенты разом начнут выполнять тяжёлые запросы, тут уже по другому может быть.Чтобы правильно поставить тест - нужно, на мой взгляд, понимать механику процесса и то, какие именно узкие места ищем. Понятно, что не фокус - сгенерировать execute block с сотней-другой разных событий и выполнить его, вопрос в том, как это повлиять может на сам сервер.
Тяжелых запросов не ожидается, речь о том, чтобы в нужных местах выставить маркеры о наличии изменений, реагировать на которые уже руками будут пользователи (и, конечно, не синхронно).

Dimitry SibiryakovУ сервера есть кусок памяти со счётчиками событий. По коммиту транзакции эти счётчики
изменяются и подписанным клиентам рассылаются пакеты новых счётчиков. Вот и вся механика.Понятно. Значит в моих объемах 10 событий или 50 - серверу по сути все равно. Спасибо.