Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Как сделать мгновенно? [D7, MySQL]

Страницы: < 1 2 3 >
FBuilder © (2008-01-16 13:11:00)
Есть база данных удаленное на по локальной сетке.
Есть таблица (SQL запрос), которая отображает ее состояние.

табилца отображается пользователю - он ее видит, может по ней пробежаться.
записей порядка 100.

проблема: табилца обновляется по такймеру - ра зв 3 секунды.
сейчас получается что это все занмиает около 250 при апдейте :( У пользователя соответственно гладкого перемещения по таблице - нет - при обновлении все замирает и скрол - дергается.

Вопрос: как добиться более гладкого хождения пользователя по обновляемой таблице?

Mysql 4.0.x, DBExpress, dbx4mysql.dll

?

Kolan (2008-01-16 16:45:00) [21]
> номер каротчки или скидки, нал безнал

Очень нужная оперативная инфа. Без номера карточки никак :)

Проанализируй как они используют инфу. Но на вскидку:

Адрес, Имя клиента, Телефон, Статус(я так понял это типа не приехал еще/отвозит…), время подезда водителя

Все, остальное в открывать в отдельном окне, по желанию пользователя.
Кроме того твои 20 полей на монитор как помещаются? Неужели бедняги скролят еще и в бок 0_o?

FBuilder (2008-01-16 16:34:00) [22]
2Kolan

Их ему нужно видеть в таблице:
чтобы не перечислять: удрас подачи (улица, дом, квартира, подезд, примечание).
телеофн, име клиента, нал безнал, номер каротчки или скидки.
время создания, время выдачи, время подезда водителя, предварительное вермя, время с клиентами,
статус.

это основные + есть дополнительные ка километражы, простои и т.д.

запрос я оптимзировал - вопросов нет.
как мне оператично ланные в DBGrid из паралелльного потока забрасывать?

Kolan (2008-01-16 16:31:00) [23]
Человек в принципе не может следить за 20 парам параметрами в 100 строках, которые обновляются каждые 3 сек или чаще…

Kolan (2008-01-16 16:23:00) [24]
> оперативно инфы обычно колонок 20

Ого, не верю. имхо 2-3 достаточно, ну 5 … но не 20. Отсюда ноги растут… Выкладывай что за поля…

Правильный_Вася (2008-01-16 16:22:00) [25]

> Директору ты расскажешь?

директору эти записи как на заборе - сто лет снились

> перелопатить всю прогу так как изменений в эту таблицу может
> вноситься в более чем 20 мест

чтобы рыбку съесть, надо в воду лезть
зачем ты однои тоже делаешь в разных местах разными способами?

> контролировать синхронизацию времени на клиентах.

причем тут клиенты - время на сервере БД одно на всех

FBuilder (2008-01-16 16:21:00) [26]
> Не обижайся, но кажется ты лукавишь. Какие там еще источники? Парк автомобилей меняется на ходу что ли? Что-то не очень вяжется с заказами такси.
Интернет заказы, СМС заказы.
Данные от водителей, которые поступают через звонок на миниАТС и отдельная программа находит этого водителя в списке текущих заказов и меняем ему статус в соответствии с тем, на какой номер позвонил водитель.
Много, поверь (это перечислено только то, что в этом такси, а есть еще и другие клиенты).

> Если свести задачу к только ОПРАДАННОМУ обновлению, то о безобидности может не надо будет беспокоиться?

Думал, прикидывал
Вкратце, если посчитать, то там выходит и так обновление раз в 3 секунды 50% вероятность что принесет новые данные при этом потоке заказов.

Поясни мне простую весчь: делаю отдельный TSimpleDataSet
в него в паралелльном потоке отдельным коннекшеном никого не трогая гружу данные - все ок.

Как мне эти данные потом быстренько отобразить или перекинуть их в ото SimpleDataSet из которого Grid смотрит (уже день за этим - немного туплю...)

Sergey13 (2008-01-16 16:14:00) [27]
> [29] FBuilder (16.01.08 16:05)
> Пробелма - изменений туда может поступать из слишком разных
> и не только зависящих от меня источников

Не обижайся, но кажется ты лукавишь. Какие там еще источники? Парк автомобилей меняется на ходу что ли? Что-то не очень вяжется с заказами такси.

> задача не уменьшить количество обновлений а сделать сам
> процесс обновления безобидней для польозвателя.

Если свести задачу к только ОПРАДАННОМУ обновлению, то о безобидности может не надо будет беспокоиться?

FBuilder (2008-01-16 16:07:00) [28]
2Kolan

оперативно инфы обычно колонок 20, строчек 100. Просмотре дополнительно - оно понятно. Но вот эти стточки все равно на локалке при текущем железе дают 200 мс отклика у мускула.
хочется этот отклик спрятать от юзвера просто и он будет счастлив!

FBuilder (2008-01-16 16:05:00) [29]
2Sergey13
Пробелма - изменений туда может поступать из слишком разных и не только зависящих от меня источников - поэтому добавление подообной вещи - нет.

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

Kolan (2008-01-16 16:04:00) [30]
Мое имхо оперативной инфы должно быть не много. И загружать её будет быстро. А если юзер захочет детально просмотреь вызов какой нить, то тогда все и загружай…

Sergey13 (2008-01-16 16:02:00) [31]
> [26] FBuilder (16.01.08 15:58)

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

ЗЫ: А тригеров в твоей мускулатуре нет еще?

FBuilder (2008-01-16 15:58:00) [32]
2 Sergey13
В таблице около 40 полей (из которых читается часть) и несколько мемо, содержание которых внутри тоже может поменяться незначительно, но это есть изменение.
как мне такое контролировать и с чем сравнивать - держать табилцу паралелльную - тяжело :(

FBuilder (2008-01-16 15:56:00) [33]
2Правильный_Вася

> Текущий список заявок в такси компании.
не нуждается в обновлении каждые 3 сек

Директору ты расскажешь?

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

> план запроса надо смотреть, а не индексы лепить
Еще раз проблема:
ЕСТЬ длительный запрос к таблице - нужно чтобы УИ не тормозило при обновлении информации, а не лечить как этот запрос исправить

Sergey13 (2008-01-16 15:54:00) [34]
> [20] FBuilder (16.01.08 15:30)
> Нереально - поиск обновлений будет грузить мускул на время
> гораздо большее чем нужно (даже с другого компа).

Почему это?
select * from ... where ...
и например
select sum(id) from ... where ...
будут по разному нагружать твой мускул? Второй может и пошустрее даже работать.

Kolan (2008-01-16 15:46:00) [35]
> Текущий список заявок в такси компании.

да понял я, что конкретно, аддрес, дата, имя водителя, средняя температура двигателя , что именно?

Правильный_Вася (2008-01-16 15:41:00) [36]

> Текущий список заявок в такси компании.

не нуждается в обновлении каждые 3 сек

> Нереально - поиск обновлений будет грузить мускул на время
> гораздо большее чем нужно

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

> делал - там пару джоинов есть - но индексы по ним уже стоят

план запроса надо смотреть, а не индексы лепить

FBuilder (2008-01-16 15:40:00) [37]
Как-то можно обновлять TSimpleDataSet в паралелльном потоке, а потом применять в табилце все в главном?

FBuilder (2008-01-16 15:30:00) [38]
> Sergey13 ©
Нереально - поиск обновлений будет грузить мускул на время гораздо большее чем нужно (даже с другого компа).

> Kolan ©
Текущий список заявок в такси компании.

Sergey13 (2008-01-16 15:09:00) [39]
> [0] FBuilder (16.01.08 13:11)

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

Kolan (2008-01-16 14:56:00) [40]
Афтар объясни что должен видеть пользователь?

Страницы: < 1 2 3 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »