fankhmпочитал про "технология Push".

не понял как её реализовать в моём случае ?
Как-нибудь с помощью третьего звена :) И оно не обязательно должно быть между клиентом и СУБД. Это может быть сервис/служба/демон/консольное приложение/что угодно. Оно где-то висит, и слушает например сокет. В этот сокет пишут все твои "клиентские места" при создании заказа. Когда оно получает заказ, оно рассылает всем "операторским местам" информацию о новом заказе (через такой же сокет напримре). Это может быть только его ID (и тогда "операторские места" сами ломануться в базу и вычитать заказ) или полная информация по заказу (тогда операторским местам остается только отобразить его в интерфейсе).

Основная идея, это именно то что ты процитировал - сервер инициирует передачу данных клиенту, а не клиент по таймеру дергает сервер.

fankhmпро "будет увлекательный танец по граблям" тоже не очень понятно. если работает чётко по транзакциям, в чём может быть проблема ?

я вижу только проблему в сборе "мусора" и обновлении статистики индексов, но это обычное, знакомое и предсказуемое.Ивенты в FB не умеют быть параметризируемыми. То есть при добавлении нового заказа ты не сможешь его ID запихнуть в ивент и разослать всем операторам ивент "Читайте заказ с ID=:pID". В результате, для реализации оповещения операторов о новом заказе нужно или писать третье звено (как я описал выше) или городить страшный огород из таблиц логирования и тригеров на комит транзакции. Обычно второй вариант не рекомендуют т.к. он и есть тот самый "увлекательный танец по граблям".

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

kdvpastorесли значение с последнего раза поменялось - перечитываем все.
все перечитывать не обязательно. Иногда добавляют в таблицу столбец, в который при insert и update пишется значение генератора +1. И тогда можно выбрать все, что вставлялось или менялось с момента последнего получения генератора. Облом разве что с удалениями. Но в приличных системах данные не удаляют :-)Еще облом, если пишущие транзакции разной длинны. Может сложится так, что транзакция обновившая поле флага еще не закомитилась. В результате, читающая транзакция эти обновления пропустит, а значение генератора последнего апдейта запомнит, и уже никогда не прочитает, что там обновила та длинная пишущая транзакция.

fankhmне могу понять про "страшный огород".Пока у тебя заказов мало - ни в чем. Каждый раз вычитываешь все не закрытые, и всё ок. Но когда у тебя появятся предварительные заказы, сама таблица заказов разрастется с 10-15 полей до 100+, или произойдет другое "внеплановое" увеличение размера вычитываемого пакета данных, тогда ты захочешь читать только то что изменилось. А это уже приведет к логу изменений и тригеру на комит генерирующему ивент для операторов. Вот это те самые грабли, а если заказов мало - как реализовывать, это скорее эстетический вопрос.

fankhmAndrey_И кстати, а как у тебя операторы будут между собой решать, кому достанется заказ? Если несколько свободных одновременно.так же как в случае с "оповещателем" - кто первый нажал "Принять", тому и разворачивает на экран состав заказа для выполнения и фиксирует этого оператора в Исполнители.
Или здесь возможны какие-то варианты ?Если с сериализацией (холостой апдейт/select with lock/etc) делать, все будет ок. А вот если так как я думал в этом топике - могут быть нюансы.