shura223Сабж. Смысл в том, что у клиента должно появиться оповещение, если произошло некоторое изменение в БД. Периодический опрос базы для такого, ИМХО, будет неправильным решением. Может сам сервер способен послать определенному клиенту сигнал, когда это требуется, а клиент уже, получив его, будет слать запрос в базу на информацию.

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

можно базе разрешить помоему запуск внешних команд, и тут тоже Делай что хочешь --не уверен что второе можно, но помню тема поднималась, и вроде через какойто плагин ктото нашол решение.


влюбом случае это криво и косо. база - это хранилище данных. задача вцелом сравнима чтобы дискета, винчестер, сд посылал сигнал что чтото на нём произошло. симкарта чтобы оповещала телефон что у неё место закончилось


это всё ересь. нормально чтобы в базу приложение обращалось ...

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

вадяавторЕрунда это всё. При правильно построенной системе такой check-запрос больше нагрузит сетевую подсистему сервера, чем сам SQL-сервер. И уж во всяком случае это будет дешевле, чем запуск стороннего приложения.
Нет, никто не мешает написАть UDF-ку с пуш-сервером. Но не дофига ли чести такой мелкой задаче?
вопрос о нагруженности в целом для ситемы, а не конкретно для sql сервера. даже при нынешних мощностях.
для однопользовальской системы - всё по-барабану.
но для хорошо нагруженных - это просто снижение кпд системы и дополнительное требование к железу.
к примеру реальное обновление раз 5-10 секунд, 1000 клиентов, требование: оперативное обновление- что будет с сервером?
1000 запросов в секунду - это много или нет? кпд близок к нулю.
udf вполне подойдет.
http://dba.stackexchange.com/questions/39522/execution-of-a-java-program-by-a-trigger
в общем ничего сложного.

тычяча клиентов в 5-10 секунд - это нагрузка?.

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

вот несёшь ты 30 кг веса - нагрузка ? нет, это просто вес. вот если ты подымаешь тяжесть и растягиваешь мышцы - вот это высокая нагрузка.

1000 одновременных подключений к базе... у меня на сервере когда 1000 подкючений, происходит что... 1000 подключений в разные участки дерева дописывают новый елемент, и идет перещот агрегированных данных заданием с запуском раз в секунду. и как тебе сказать про нагрузку...1000 подключений, для простоты возьми на коме и в цикле 1000 раз сгенерируй данные на 4кб и запиши их в отдельный файл, посмотри на время, вторым заходом в цикле щитай эти 1000 файлов меняя в них чтото и записывая... засеки время.. сколько времени подобное на лептопе занимает?!


для наглядности



это на наутбуке, далек не и7. и не ссд диск - и торенты не отключал

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

вадяну я могу привести пример, когда скачивание торентов кладет далеко не слабую машину...
надо рассматривать всю систему в целом.
и если есть новые методы обеспечивающие более "правильную" работу систему - надо научиться их использовать.
если есть возможность заменить 1000 обращений к серверу в сек на рассылку от сервера раз 10сек - разве не стоит использовать такое?

я написал пример, исключительно к фразе 1000 клиентов за 15 секунд создают нагрузку на сервер. лишь пример что это не нагрузка.

а сдесь надо смотреть исключительно на архитектуру.

зачем мы часто обращаемся..если чтобы часто получать данные, то надо обращаться и получать.

если же мы хотим просто в режиме реального времени узнавать о изменениях - надо оповещать.

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

(а то какбы на 1000 клиентов которым раз в 5сек надо новые данные получить) брать ещо 1000 спамов пускать по сети, тоже не блещет результатом решение.

ЗЫ
IT - первая буква не зря означает информационные. и основная задача - передавать информацию, а не данные.
если на 1000 обращений 999 будут холостые, то это не получение информации - это получение муссора.

если на 1000 обращений 999 забирают данные, и мы 1000 делали оповещений - последнее такойже мусор. зачем передавать по сети то, что и так извесно.

вот моя точка зрения относительно того, стоит или не стоит использовать оповещения.

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

User difined function - не утверждаю, а лишь предполагаю, что как и везде это костыль... тоесть то что существенно понизит производительность.

то наверно лучше по крону.

ЗЫ
мыж понимаешь что скомпилированя процедура на языке мускла в байткод, это по сути ....

скажем у субд есть своя работа по работе с автоинкрементом...где есть команда по сути

по адресу записаным тамто, взять значение, и добавить единицу.

то байт код полученый из строки set @a=@a + 1; будет аналогичным.

сделать такойже юдф, єто запуск отдельной программы, если посмотреть в глубь, копирование туда окружения, и запуск тамошнего кода. вот это копирование и запуск отдельного процесса, и понижает производительность.

подозреваю что если (udf наша пускай somefunc(a,b,c):integer )
то если в триггере вообще сделать вместо

IF @need > 0 THEN
NEW.a = somefunc(a,b,c);
ELSE
NEW.a = 0;
END IF;

NEW.a=somefunc(a,b,c); а условие надо или не надо щитать перенести в юдф, то этим сразу
и на 1000 запросов в 10 секунд возможно положим сервер.

хотя если я ошибаюсь, и привлечение юдв(лучше всего на тригере проверить) не меняет существенно производительности, то да можно расматривать.