ProgressBar при SQL-запросе.

← →
АндрейБ (2003-02-20 15:58) [0]

Подскажите, как можно определить приблизительное время SQL-запроса. Хотелось бы, чтоб появлялось окно с ProgressBar или что-нибудь вроде этого.

← →
stone © (2003-02-20 15:59) [1]

Никак.

← →
Anatoly Podgoretsky © (2003-02-20 16:03) [2]

Один раз замерить, результат сохранить и в дальнешим им пользоваться.

← →
АндрейБ (2003-02-20 16:11) [3]

>Anatoly Podgoretsky
Это не выход, т.к. база постоянно пополняется.

А может можно определить объем выполненного. Или лучше просто выдать сообщение "Ждите..."?

← →
Johnmen © (2003-02-20 16:24) [4]

"Ждите..." самое оно !

← →
АндрейБ (2003-02-20 16:36) [5]

>Johnmen
Спасибо

← →
passm © (2003-02-20 16:40) [6]

"Ушла на базу данных..."

← →
Anatoly Podgoretsky © (2003-02-20 16:46) [7]

АндрейБ (20.02.03 16:11)
А ты корректируй после каждого запроса.

← →
Виталик (2003-02-20 17:33) [8]

Т.е. в итоге получится, что при очередном запросе его приблизительное время выполнения будет равно ыремени выполнения предыдущего запроса? В общем-то вариант.

← →
АндрейБ (2003-02-20 17:35) [9]

Anatoly Podgoretsky (20.02.03 16:46)
Спасибо за вариант, но пока мне, я думаю, будет достаточно просто "ЖДИТЕ"

← →
Desdechado © (2003-02-21 10:45) [10]

поставь progressbar, который как только дойдет до конца, начинает сначала. Юзер видит, что не зависли, и ждет :)

← →
Johnmen © (2003-02-21 11:01) [11]

>Desdechado © (21.02.03 10:45)

А кто и когда будет ему говорить идти ?

← →
Виталий Панасенко (2003-02-21 11:02) [12]

В RxLib это есть. Используются callback-функции и пример есть(работает), но у меня ничего не вышло :-(

>Anatoly Podgoretsky © (21.02.03 12:04)
Тогда конечно...Только неясно, как будет инициироваться очередной step прогрессбара...

Для парадокса в свое время мы делали замеры и даже прописали для себя формулу определения веремени ожидания выполнения запроса. Довольно сложная формула, куда входило множество аргументов: кол-во записей в таблице, кол-во выбираемых полей и их длина, наличие индексов, примерный процент (или кол-во) ожидаемых выходных записей и т.д. На связанных запросах коэффициенты как-то хитро перемножались. Самое главное, что получали характеристики, довольно приближенные к реальным затратам времени. Но один минус - все это хорошо работало только на локальном диске. Как только ставилось на сетку, все характеристики летели к черту ;)

И еще. На связанные запросы к таблицам больших размеров (начиная от 1000*5000) ставили порезку на "порции". Результаты были просто ошеломительные. Так при связанном запросе с хотя бы одной неключевой таблицей при объемах данных порядка 5000*50000 записей скорость "порезанного" алгоритма повышалась в СОТНИ раз !
Правда это для 3.5. Для 4-го и более старших эффект был не такой впечатляющий.

ProgressBar при SQL-запросе. Найти похожие ветки