| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Locate в InterBase [D7, IB5.x]
ivb2001 © (2004-02-11 15:15:00)
Please, почему жутко медленно работает TibQuery.Locate c IBase? Всего-то 3к записей. Пришлось написать свой поиск, но этоже средневековье! За что боролись!!!
ivb2001 (2004-02-13 13:49:00) [1]
Еще раз всем спасибо!
Позвольте считать собрание закрытым.
P.S.
to Johnmen © (23.01.04 13:43) [14] Поле ZAKAZDATE не предназначено для ввода. Оно заполняется автоматом при создании новой записи текущей системной датой и потому пустым быть не может по определению. Конечно надо было подстраховаться, но, сам понимаешь, - то руки не доходят, то ноги не доносят...
Соловьев (2004-02-12 17:00:00) [2]
Это ты себе можешь пару раз 300 тыс скопировать в ОП, а если у клиента не ахти с памятью? или сеть не очень? то что тогда?
Vlad (2004-02-12 16:36:00) [3]
> Соловьев © (12.02.04 16:24) [18]
Если сделать FetchAll сразу после открытия НД, то локейты будут пулять со свистом, вчера проверял на 300 тыс записей - доля секунды.
Соловьев (2004-02-12 16:24:00) [4]
смысл в том что если нет записи ты не будешь тянуть все записи при Locate клиенту. а это согласись полезно.
Vlad (2004-02-12 16:23:00) [5]
> Соловьев © (12.02.04 15:26) [16]
Я про то что сначала делать автономный select, а потом Locate - особого смысла не вижу.
А отключение AfterScroll (если там что-то есть) естественно поможет, но опять же не всегда бездумно можно его отключать, сам понимаешь.
Соловьев (2004-02-12 15:26:00) [6]
2 Vlad
ну и причем AfterScroll к индексу?
Я про то что когда используют перемещение по записям, то желательно убрать обработку события AfterScroll
Vlad (2004-02-12 15:04:00) [7]
Я тут проверил, Locate в IBQuery работает одинаково что по ключевым что по неключевым полям, индексы никак не влияют.
В справке явный обман.
Так что смысла в [10] скорее всего нету.
Так что вариант один - фетчить все записи на клиента, как сказал Johnmen © (11.02.04 15:32) [4]
Deniz (2004-02-12 07:09:00) [8]
Если select ... order by field1а locate по field2, то индекс врядли будет использоваться, даже если он есть :(
Sandman25 (2004-02-11 17:20:00) [9]
[10] + получается, что кроме AfterScroll желательно вызвать и DisableControls. Может замедление из-за перерисовки грида?
Соловьев (2004-02-11 17:15:00) [10]
Я делаю сначала запрос к БД(select ... where ), и если запись есть , беру ключевое поле и только тогда иду Locate, и еще желательно отключить AfterScroll на этом НД.
Anatoly Podgoretsky (2004-02-11 16:57:00) [11]
Еще раз, откуда индекс у запроса, конечно он бы ускорил.
Vlad (2004-02-11 15:47:00) [12]
> Anatoly Podgoretsky © (11.02.04 15:40) [7]
Получать всезаписи на клиента м.б. накладной процедурой, если их много. А последовательный фетч с сервера теоретически может ускорить если по этому полю есть индекс. Иначе, как по-другому объяснить строчки из справки ?
Anatoly Podgoretsky (2004-02-11 15:40:00) [13]
Какие индексы у возращенного запроса, Locate работает на клиенте, последовательный перебор, но на трех тысячах практически мгновенно, конечно сначала надо получить все записи на клиента.
VLAD-MAL (2004-02-11 15:37:00) [14]
Может, у него в Locate поиск по 25 ключам...
Vlad (2004-02-11 15:36:00) [15]
Вот строчка из хелпа:
Locate uses the fastest possible method to locate matching records. If the search fields in KeyFields are indexed and the index is compatible with the specified search options, Locate uses the index. Otherwise Locate creates a filter for the search.
Так что можно воспользоваться советом и просто проиндексировать поле.
Johnmen (2004-02-11 15:32:00) [16]
После TibQuery.FetchAll искать должно быстро.
На CELERON1000 SDRAM100 на 3000 записях простое сканирование с проверкой (результат положителен на последней записи) время ~0.4 сек.
VLAD-MAL (2004-02-11 15:20:00) [17]
Ну, так создай свой, отдельный TibQuery с
Select * where (супер-пупер условия поиска)
и если план запроса будет удачный, все будет OK!
Еще варианты: может, у тебя много длинных Varchar - полей. Так вот, они только хранятся компактно, а по сети все пустышки перегоняются. Переходи на FireBird 1.5
HSolo (2004-02-11 15:20:00) [18]
Лично я борюсь за ограничение выборки :))
А что делается с этими 3к записей? Показ в гриде + поиск на клиенте?
Vlad (2004-02-11 15:19:00) [19]
> ivb2001 © (11.02.04 15:15)
Посмотри реализацию - там полный перебор по всем записям. Чего ты хочешь ?
Кстати, обещают что поиск будет быстрым если поле в таблице проиндексировано.
Johnmen (2004-01-23 13:43:00) [20]
>ivb2001 © (23.01.04 13:28) [13]
Немного не в тему - как удалось создать уникальный индекс с использованием поля (ZAKAZDATE), для которого м.б. NULL ?
| |
Страницы: 