Как организовать обновление отображения данных?
Модератор: kdv
-
- Сообщения: 250
- Зарегистрирован: 25 июл 2007, 21:33
Как организовать обновление отображения данных?
Суть - есть приложение реального времени. Отображение изменений должно быть практически мгновенным! Раньше, в старой версии (Paradox) это решалось Refresh основных таблиц, который делался раз в 2 секунды.
В FireBird (2.0.1) как и в любой "взрослой" РСУБД есть триггеры. Я правильно понимаю, что на AfterInsert или AfterUpdate нужно генерировать некоторые действия, по обновлению основных таблиц?
Как это выглядит на практике? Приложение на Delphi - что надо указать в триггере в качестве действия? Как приложению передать необходимость апдейта таблиц или отдельных элементов?
В FireBird (2.0.1) как и в любой "взрослой" РСУБД есть триггеры. Я правильно понимаю, что на AfterInsert или AfterUpdate нужно генерировать некоторые действия, по обновлению основных таблиц?
Как это выглядит на практике? Приложение на Delphi - что надо указать в триггере в качестве действия? Как приложению передать необходимость апдейта таблиц или отдельных элементов?
Re: Как организовать обновление отображения данных?
Как связаныKotъ-Begemotъ писал(а):Суть - есть приложение реального времени. Отображение изменений должно быть практически мгновенным! Раньше, в старой версии (Paradox) это решалось Refresh основных таблиц, который делался раз в 2 секунды.
В FireBird (2.0.1) как и в любой "взрослой" РСУБД есть триггеры. Я правильно понимаю, что на AfterInsert или AfterUpdate нужно генерировать некоторые действия, по обновлению основных таблиц?
Как это выглядит на практике? Приложение на Delphi - что надо указать в триггере в качестве действия? Как приложению передать необходимость апдейта таблиц или отдельных элементов?
иОтображение изменений
Так отображать или менять?нужно генерировать некоторые действия, по обновлению основных таблиц?
Если отображать, то возможно подойдут Events
но с трудом я поверю, что
Тебя пользователи просто закопаютОтображение изменений должно быть практически мгновенным!
http://forum.ibase.ru/phpBB2/viewtopic. ... B%F2%E8%FF
Такое "приложение реального времени" я могу придумать только одно - которое показывает ползателю некую динамику изменения чего-то, без возможности вмешаться в то, что показывается.
Решение "в лоб" - выполнение запроса по таймеру. Разумеется, получаться должны только те данные, которые будут отображаться.
Решение "в лоб" - выполнение запроса по таймеру. Разумеется, получаться должны только те данные, которые будут отображаться.
-
- Сообщения: 250
- Зарегистрирован: 25 июл 2007, 21:33
Поясню. Пользователи закапывать меня не будут, и данные менять нужно а не только отображать. Чтобы было понятнее:WildSery писал(а):Такое "приложение реального времени" я могу придумать только одно - которое показывает ползателю некую динамику изменения чего-то, без возможности вмешаться в то, что показывается.
Решение "в лоб" - выполнение запроса по таймеру. Разумеется, получаться должны только те данные, которые будут отображаться.
Программа - менеджер такси. Сидят диспетчера - есть те что на приёме звонков, есть те, что на рации(ях) Находятся они "через стену" то есть прямого доступа друг к другу нет. Нужно видеть всю динамику парка, особенно тем, которые на рации, так как они по факту не только диспетчера, но еще и в общем-то менеджеры, которые не просто тупо раздают заказы, а следят за ситуацией, принимая различные решения по оптимизации работы...
Так вот - поступил заказ, диспетчер на телефоне его набил - нужно чтобы он как можно быстрее появился у диспетчера на рации. Соответственно заказ отдан таксисту, в окне парка это такси должно отобразить, что уже не "свободен" а "выполняет заказ", и соответственно заказ должен стать "Выполняется". Тут задержки очень критичны - нужна скорость отображения, вот я и спросил. Но почему-то мало кто может поверить что нужна такая скорость. Я вас уверяю - НУЖНА! Борьба идёт за каждую секунду (в том числе и при вводе данных). Вот я и думаю как это правильно в РСУБД организовать можно...
-
- Сообщения: 250
- Зарегистрирован: 25 июл 2007, 21:33
Что значит когда ему удобно? Сидеть и капой клацать?!? Нужно видеть обновления сразу! Насчет баяна не знаю, ничего интересного в этом плане не видел...Merlin писал(а):Баян это. Именно про такси. На каждом АРМе выполнять фуллрефреш после обработки каждой заявки, в режиме ожидания поджигать надпись "есть свежатинка" по эвентам, рефрешить по кнопке когда ему удобно.
-
- Сообщения: 250
- Зарегистрирован: 25 июл 2007, 21:33
Блин. Да представь ты наконец себя на месте ползателя.
Если операторы будут молотить изменения каждые две секунды, он вообще только открыв рот будет пялиться в экран.
Аналогия в "покадровом просмотре" не просматривается. Гы. Я ж тебе предложил решение, чтобы он сидел и просто смотрел, а все время от времени рефрешилось. Но не постоянно.
А если начинает руками вмешиваться - чтобы в это время не обновлялось, делало временной отступ от последнего действия ползателя, прежде чем опять начать автоматом обновляться.
Если операторы будут молотить изменения каждые две секунды, он вообще только открыв рот будет пялиться в экран.
Аналогия в "покадровом просмотре" не просматривается. Гы. Я ж тебе предложил решение, чтобы он сидел и просто смотрел, а все время от времени рефрешилось. Но не постоянно.
А если начинает руками вмешиваться - чтобы в это время не обновлялось, делало временной отступ от последнего действия ползателя, прежде чем опять начать автоматом обновляться.
-
- Сообщения: 250
- Зарегистрирован: 25 июл 2007, 21:33
Да на месте пользователя я как раз себя очень хорошо представляю, и поток заказов тоже хорошо знаю. Для примера - он БОЛЬШЕ чем в московском Новом Желтом Такси, при том, что там одних операторов под 20 человек, а тут всего диспетчеров (и на телефонах и на рациях) 5-6 человек. Какие тут еще дополнительные кнопки? Особенно для тех кто на рации, которые должны видеть сразу изменение состояния водителей (другой диспетчер по просьбе водителя мог поставить ему "Ремонт" или "Обед") и заказов ,появление дополтинельных поменто на заказах и так далее... В Paradox вариантов не было - приходилось рефрешить по таймеру постоянно. А в РСУБД вроде как есть события, вот хотелось бы по ним и изменять только те данные, которые реально поменялись, вот и думаю реально ли это, или РСУБД для подобных задач не "заточены"? Хотя по идее должно быть можно сделать, вопрос КАК?WildSery писал(а):Блин. Да представь ты наконец себя на месте ползателя.
Если операторы будут молотить изменения каждые две секунды, он вообще только открыв рот будет пялиться в экран.
Аналогия в "покадровом просмотре" не просматривается. Гы. Я ж тебе предложил решение, чтобы он сидел и просто смотрел, а все время от времени рефрешилось. Но не постоянно.
А если начинает руками вмешиваться - чтобы в это время не обновлялось, делало временной отступ от последнего действия ползателя, прежде чем опять начать автоматом обновляться.
Я сталкивался с такой задачей. В ней не требуется именно "реалтайм".Kotъ-Begemotъ писал(а): Да на месте пользователя я как раз себя очень хорошо представляю, и поток заказов тоже хорошо знаю. Для примера - он БОЛЬШЕ чем в московском Новом Желтом Такси, при том, что там одних операторов под 20 человек, а тут всего диспетчеров (и на телефонах и на рациях) 5-6 человек. Какие тут еще дополнительные кнопки? Особенно для тех кто на рации, которые должны видеть сразу изменение состояния водителей (другой диспетчер по просьбе водителя мог поставить ему "Ремонт" или "Обед") и заказов ,появление дополтинельных поменто на заказах и так далее... В Paradox вариантов не было - приходилось рефрешить по таймеру постоянно. А в РСУБД вроде как есть события, вот хотелось бы по ним и изменять только те данные, которые реально поменялись, вот и думаю реально ли это, или РСУБД для подобных задач не "заточены"? Хотя по идее должно быть можно сделать, вопрос КАК?
Лучшим решением будет все же обновление по таймеру и правильное выстраивание логики работы приложения.
Статус водителей можно обновлять по событиям.
Но если их много или обносляются состояния часто, то лучше считывать только "дельту", а не всех водителей каждым запросом. Правда если изменеиня происходят очень часто (несколько раз в секунду), то лучше здесь от событий отказаться.
-
- Сообщения: 250
- Зарегистрирован: 25 июл 2007, 21:33
Меняются часто, но все же не несколько раз в секунду, конечно состояния водителей. Поэтому тоже думаю как-то по событиям обновлять... А по количеству - ну одновременно может быть теоретически водителей 300 думаю вряд ли больше... То есть надо триггиры писать и по ним обновлять?ivl писал(а):Я сталкивался с такой задачей. В ней не требуется именно "реалтайм".Kotъ-Begemotъ писал(а): Да на месте пользователя я как раз себя очень хорошо представляю, и поток заказов тоже хорошо знаю. Для примера - он БОЛЬШЕ чем в московском Новом Желтом Такси, при том, что там одних операторов под 20 человек, а тут всего диспетчеров (и на телефонах и на рациях) 5-6 человек. Какие тут еще дополнительные кнопки? Особенно для тех кто на рации, которые должны видеть сразу изменение состояния водителей (другой диспетчер по просьбе водителя мог поставить ему "Ремонт" или "Обед") и заказов ,появление дополтинельных поменто на заказах и так далее... В Paradox вариантов не было - приходилось рефрешить по таймеру постоянно. А в РСУБД вроде как есть события, вот хотелось бы по ним и изменять только те данные, которые реально поменялись, вот и думаю реально ли это, или РСУБД для подобных задач не "заточены"? Хотя по идее должно быть можно сделать, вопрос КАК?
Лучшим решением будет все же обновление по таймеру и правильное выстраивание логики работы приложения.
Статус водителей можно обновлять по событиям.
Но если их много или обносляются состояния часто, то лучше считывать только "дельту", а не всех водителей каждым запросом. Правда если изменеиня происходят очень часто (несколько раз в секунду), то лучше здесь от событий отказаться.
-
- Сообщения: 250
- Зарегистрирован: 25 июл 2007, 21:33
Дык вот это я и пытаюсь пока осмыслить - по каким событиям, как реагировать и так далее... Пока плаваю еще в этом, читаю книшшку вумную Хелен Борри - Firebird: Руководство разработчика баз данных и "много думаю" ))WildSery писал(а):Ну почему же. Всего лишь не нужно бросаться что-то делать по каждому событиюivl писал(а):то лучше здесь от событий отказаться.
Ну вот и славненько. Организуй рефреш с 15-сек интервалом и по кажному событию впридачу, нехай у ползателя в глазах от живущего богатой внутренной жизнью экрана рябит, строчки из-под мыша в момент клика уползают, нажимая на одну строчку, получает доступ к другой и так далее. А то ведь и вправду - нажать капу, когда готов к новой порции информации, это не гламурно, не готично и вломно. Заодно и сервак с сеткой затрахаешь, а то за что деньги плочены, нехай пашуть.Kotъ-Begemotъ писал(а): Дык вот это я и пытаюсь пока осмыслить - по каким событиям, как реагировать и так далее... Пока плаваю еще в этом, читаю книшшку вумную Хелен Борри - Firebird: Руководство разработчика баз данных и "много думаю" ))
Как я понял ему необходимо получать информацию прежде всего о статусе водителя в "реалтайм"?Merlin писал(а): Ну вот и славненько. Организуй рефреш с 15-сек интервалом и по кажному событию впридачу, нехай у ползателя в глазах от живущего богатой внутренной жизнью экрана рябит, строчки из-под мыша в момент клика уползают, нажимая на одну строчку, получает доступ к другой и так далее. А то ведь и вправду - нажать капу, когда готов к новой порции информации, это не гламурно, не готично и вломно. Заодно и сервак с сеткой затрахаешь, а то за что деньги плочены, нехай пашуть.
Нет здесь никакого мельтешения и уползания не будет, если все запрограммировать правильно -- фиксированное число записей очень этому поможет. Если для этой цели не использовать DBGrid, а, например, простой Grid, куда информация набивается вручную (например номер водителя и его статус), и каждая ячейка или строка на одном и том же месте. В таком случает очень наглядно видно кто изменил статус и на что (особенно если цветом выделять). А если ещё не гонять всю таблицу, а только последние изменеиня, то и сеть нагружаться в пустую не будет.
-
- Сообщения: 250
- Зарегистрирован: 25 июл 2007, 21:33
Рябит в глазах или нет, это вопрос второй. Диспетчеру на рации нужно видеть весь парк и изменение состояний, потому что этот диспетчер на основании данной информации принимает ряд решений. Строчки из под мыша никуда не бегают просто потому что у меня не используются гриды для рабочей информации. Вообще. Только в справочниках и отчётах. Нажать капу не негламурно, а некогда. Я еще раз повторю- борьба идёт за каждую секунду, потому что эти секунды складываются в минуты, которые клиенты висят на телефонах. Самому небось не понравится ждать по 5 минут на трубке? Ребята! Отвелекитесь от ВАШИХ реалий, представьте что есть ДРУГИЕ требования. Они правда есть. Не все задачи это склады, бухгалтерии и отчётности, где не нужна такая оперативность! Есть системы управления, например, где реакция на изменение каких-то характеристик так же должна быть выведена НЕМЕДЛЕННО а не по нажатию некой клавиши и не раз в 15 минут по таймеру!Merlin писал(а):Ну вот и славненько. Организуй рефреш с 15-сек интервалом и по кажному событию впридачу, нехай у ползателя в глазах от живущего богатой внутренной жизнью экрана рябит, строчки из-под мыша в момент клика уползают, нажимая на одну строчку, получает доступ к другой и так далее. А то ведь и вправду - нажать капу, когда готов к новой порции информации, это не гламурно, не готично и вломно. Заодно и сервак с сеткой затрахаешь, а то за что деньги плочены, нехай пашуть.Kotъ-Begemotъ писал(а): Дык вот это я и пытаюсь пока осмыслить - по каким событиям, как реагировать и так далее... Пока плаваю еще в этом, читаю книшшку вумную Хелен Борри - Firebird: Руководство разработчика баз данных и "много думаю" ))
Я не хочу затевать бесполезных споров. Я просто констатирую факт, что мне НУЖНО очень оперативное отображение информации, и спрашиваю совета у более опытных в РСУБД людей можно ли это сделать и как...
ЗЫ. Сетка не ляжет, прога со всеми пользователями работает на терминалке
Угу. Мы только ими всю жись и занимались.Kotъ-Begemotъ писал(а): Ребята! Отвелекитесь от ВАШИХ реалий, представьте что есть ДРУГИЕ требования. Они правда есть. Не все задачи это склады, бухгалтерии и отчётности, где не нужна такая оперативность!
И при чём здесь СУБД?Kotъ-Begemotъ писал(а): Есть системы управления, например, где реакция на изменение каких-то характеристик так же должна быть выведена НЕМЕДЛЕННО а не по нажатию некой клавиши и не раз в 15 минут по таймеру!
Мнение опытных ты уже услышал, строительством личных лисапетов как нибудь сам...Kotъ-Begemotъ писал(а): Я не хочу затевать бесполезных споров. Я просто констатирую факт, что мне НУЖНО очень оперативное отображение информации, и спрашиваю совета у более опытных в РСУБД людей можно ли это сделать и как...
-
- Сообщения: 250
- Зарегистрирован: 25 июл 2007, 21:33
А по-моему так предельно вразумительно - умные люди не делают так, чтобы информация на экране непрерывно менялась в процессе единичного акта принятия и регистрации дискретного решения. Ну надо тебе так - ты так и делай...Kotъ-Begemotъ писал(а): Да вот мнений пока не так много и услышал. Всё больше в сторону "А нафига тебе так?". Ну надо мне так... Поэтому и спросил. Ответы "динозавров" к сожалению оказались маловразумительными...