Есть ли и в каких СУБД и как эта тема называется, что бы я отправил запрос, получил управляющих хэндел на выборку, и после СУБД оповещала бы об изменениях, которые затрагивают этот запрос. Что бы не отсылать его заново по таймеру для отслеживания новых данных.
Или как это вообще делается для одно и многопользовательских СУБД?

MasterZivНо на самом деле это всё от лукавого...
Сервер должен быть всегда пассивен, это -- основа производительности СУБД. (одна из).
не согласен. Именно повторные опросы по таймеру и будут загружать сервер.
А постоянный коннект, с подпиской на изменения отображаемых на просмотр данных избавит от этого. Ну или таблички будут не обновляемые, что не очень красиво.

Спасибо ответившим.

Еще, а есть ли какие методы для такого оповещения из Qt?

MasterZivMasterZivНо на самом деле это всё от лукавого...
Сервер должен быть всегда пассивен, это -- основа производительности СУБД. (одна из).

Я хочу пояснить, если вы не понимаете.

Представьте себе БД и 10 пользователей к ней.
Каждый пользователь делает изменение. N изменений (N=10).
СУБД должна разослать оповещения, M оповещений. M = тоже 10, каждому пользователю ( в реальности может быть не каждому, а
k*N, где k < 1, но это не очень важно).

Вычислим объём работы для СУБД по рассылке.

O() = M*N = N**2

O(10 пользоват) = 100 -- вроде бы и не так страшно.

Теперь увеличиваем количество пользователей до 100 и 1000.

O(100 пользоват) = 10000
O(1000 пользоват) = 1000000

Ну и так далее...

Ну я поясню. Предположим, есть 100 пользователей, у которых в текущий момент открыто по окошку с табличкой, в которой отображается по 40 строк. Скорей всего у них будут преимущественно разные множества и таблиц и подмножества строк. И сервер должен отсылать событие, лишь тогда, когда изменение касается открытого множества. Что на стороне сервера сделать не сложно, храня индексированно активные селекты.

Отображаются в основном только таблицы введенные вручную, а не генерируемые. И изменения вручную. Т.е. одна точечная запись, должна отобразить изменения пусть будет в не более чем пяти пользователей. Это будет актуально, если это скажем таблица остатков, за которые менеджеры грызуться резервируя. Либо отослать события пяти пользователям, либо все сто, каждые 10 сек будут переопрашивать свой селект.

Но может быть Вы и правы, я просто теоретизирую.

Нудный ламерИскусственная все-таки ситуация. Невозможно, по-моему, работать по такой технологии - менеджер должен глазками следить за табличкой в окошке и реагировать на изменения. Нужно ведь помнить, в какой строке какое значение было, чтобы понять, что оно изменилось. А если было 150, потом стало 200, а через секунду снова 150 ? И прилетит ивент, что значение изменилось, а менеджер смотрит - ни фига и не изменилось, те же 150 светятся.

В таких случаях, имхо, ПО должно уметь автоматически делать нужные транзакции по заранее составленным заявкам менеджеров - например, если значение в поле достигнет 180, то делаем транзакцию.

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