Форум: "Базы";
Текущий архив: 2003.03.13;
Скачать: [xml.tar.bz2];
Вниз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 (2003-02-21 12:04) [13]Johnmen © (21.02.03 11:01)
Это должно быть в разных потоках.
← →
Johnmen (2003-02-21 12:17) [14]>Anatoly Podgoretsky © (21.02.03 12:04)
Тогда конечно...Только неясно, как будет инициироваться очередной step прогрессбара...
← →
MsGuns (2003-02-21 12:21) [15]Для парадокса в свое время мы делали замеры и даже прописали для себя формулу определения веремени ожидания выполнения запроса. Довольно сложная формула, куда входило множество аргументов: кол-во записей в таблице, кол-во выбираемых полей и их длина, наличие индексов, примерный процент (или кол-во) ожидаемых выходных записей и т.д. На связанных запросах коэффициенты как-то хитро перемножались. Самое главное, что получали характеристики, довольно приближенные к реальным затратам времени. Но один минус - все это хорошо работало только на локальном диске. Как только ставилось на сетку, все характеристики летели к черту ;)
И еще. На связанные запросы к таблицам больших размеров (начиная от 1000*5000) ставили порезку на "порции". Результаты были просто ошеломительные. Так при связанном запросе с хотя бы одной неключевой таблицей при объемах данных порядка 5000*50000 записей скорость "порезанного" алгоритма повышалась в СОТНИ раз !
Правда это для 3.5. Для 4-го и более старших эффект был не такой впечатляющий.
← →
Anatoly Podgoretsky (2003-02-21 12:27) [16]Johnmen © (21.02.03 12:17)
По таймеру, тем более что речь то идет не об абстрактном запросе.
Страницы: 1 вся ветка
Форум: "Базы";
Текущий архив: 2003.03.13;
Скачать: [xml.tar.bz2];
Память: 0.47 MB
Время: 0.006 c