Форум: "Базы";
Текущий архив: 2003.05.08;
Скачать: [xml.tar.bz2];
ВнизПоиск по индексу или Select, что быстрее через ADO? Найти похожие ветки
← →
zom (2003-04-14 12:54) [0]Ситуация такая:
при выборе некоторой строчки в гриде, необходимо по данной позиции найти значения в другой таблице.
вариант 1. используя ADOquery делаю запрос Select, который возвращает только одну строчку из другой таблицы.
вариант 2. используя ADOTable подключаю к нужной таблице, подключаю индекс по связанному полю и делаю Find(...)
(подключение индекса выполняется один раз за все время работы )
Вопросы:
- что работает быстрее? (при размерах таблиц в сотни тысяч или даже миллионы записей)
- если вторая таблица - View,а по ним индексы не строются, могу я как-то использовать Find или что-то подобное?
- если в приложении две ADOTable, подключены к одной таблице (не эксклюзивно) но с разными индексами, как они будут работать вместе (курсоры у них я так понимаю независимые получаются и вроде никак они друг на друга влиять не будут) не будут ли тормозить друг друга и какие типы курсоров в свойствах ADOtable лучше выставить
Заранее спасибо за ответы ;)
← →
Соловьев (2003-04-14 12:59) [1]
> Вопросы:
> - что работает быстрее? (при размерах таблиц в сотни тысяч
> или даже миллионы записей)
запросы быстрее.
← →
zom (2003-04-14 13:19) [2]to Соловьев
почему такая уверенность, что запросы работают быстрее?
мне же надо найти только одну запись в таблице по уникальному индексу...
я к сожалению пока не могу протестировать на больших таблицах, но на 5 000 записей оба варианта работают мнгновенно - попытка измерить милисекунды - даёт 0 в обоих случаях (база локальная)
← →
Соловьев (2003-04-14 13:31) [3]
> ADOTable подключаю к нужной таблице, подключаю индекс по
> связанному полю и делаю Find
поиск на клиенте(на сколько я знаю) и при
> при размерах таблиц в сотни тысяч или даже миллионы записей)
это существенно при работе в сети, да и локально. А вот Query делает это на серваке, что быстрее. Так как трафик не загружен ну и сервак помошнее.
← →
Anatoly Podgoretsky (2003-04-14 13:33) [4]Поиск работает по всей выборки, а запрос возвращает только одну запись, сравниваешь помидоры с табуретками.
← →
zom (2003-04-14 13:51) [5]Поиск конешно работает по всей выборке, только выборку я уже давно сделал (когда открыл Тейбл) а поиск делаю регулярно...
и если квери выполняется на сервере, а поиск на локале - получается, что при проблемах со связью (дикой загрузкой сервера) лучше пользовать Поиск...
только тут другой вопрос - поиск выполняется по всей таблице, а сколько от этой таблицы загружено на локал при открытии таблицы?
я так предполашал, что все поля, что прошли фильтры передаются с сервера на локал один раз когда вызываю Table1.Open, а потом при всяких Find обращений к серверу нету... если не вызывать всякие Refresh...
правда данные могут устареть, но в данном случае это не важно
← →
zom (2003-04-17 10:07) [6]На счёт фильтров получается по другому - таблица загружается полностью, а когда я включаю или меняю фильтр, то неподходящие записи просто отсеиваются, а обращения к базе не происходит
(я это заметил, только когда искал ответ на свой вопрос про проверку связи адоконнекшн)
Отсюда вывод: маленькие справочные таблицы (которые редко обновляются на сервере) стоит подгружать через Адотейбл и делать поиск по индексу - загружается с сервера один раз и надолго, трафик не грузится сильно и память клиента от мелких таблиц не сильно пострадает.
А по большим таблицам и по регулярно изменяемым - селект и только селект.
Вот только что делать с основной справочной таблицей: она большая, но её желательно имень полностью на клиенте, чтоб всегда можно было видеть большой набор данных и из него выбирать (например справочник товара).
В принципе тут два варианта:
1. Вся таблица загружается и по необходимости включается нужный фильтр.
2. Каждый раз как надо изменить фильтр - выполняется селект с условием по фильтру.
Уважаемые мастера! Жду ваших За и Против по данным методам.
← →
Anatoly Podgoretsky (2003-04-17 10:18) [7]Поиск и выборка две взаимно ортогональные вещию Одна перемещает курсорЪ а втора запрашивает данныеъ
Ты определись что тебе нужно.
← →
stone (2003-04-17 10:24) [8]ИМХО,
> 2. Каждый раз как надо изменить фильтр - выполняется селект
> с условием по фильтру.
потому что нет смысла хранить данные (
> основной справочной таблицей: она большая
) которые не используются.
← →
AleksandrKu (2003-04-17 11:45) [9]В таком случае я все равно пользуюсь Query но выбираю не все поля а только Id и необходимые для просмотра типа наименование а для конкретного товара выполняю другой Query
где выбираю все нужные поля но для записи с нужным Id
Но у меня есть на то причина у меня клиент за 300 км и канал 64Кб
← →
zom (2003-04-17 13:17) [10]2 AleksandrKu:
У меня всё не настолько туго ;)
и я пользую индексы...
2 stone:
А иногда нет смысла запрашивать каждый раз у базы, если юзер меняет фильтры каждые 10 секунд...
а лучше всё-таки оставить все данные на локале...
к томуже по индексу хорошо работает Find по разным полям, а как сделать так же по Квери - вопрос!
← →
Соловьев (2003-04-17 13:20) [11]
> так же по Квери - вопрос!
select field
from table
← →
stone (2003-04-17 13:22) [12]Что и как делать личное дело каждого. Если ты уверен в своей правоте, то зачем спаршиваешь совета?
> А иногда нет смысла запрашивать каждый раз у базы, если
> юзер меняет фильтры каждые 10 секунд...
> а лучше всё-таки оставить все данные на локале...
Это зависит от количества записей. Видимо тут речь идет о сравнительно не больших объемах.
> к томуже по индексу хорошо работает Find по разным полям,
> а как сделать так же по Квери - вопрос!
Это не вопрос, а уход от решения.
← →
zom (2003-04-17 14:56) [13]2 Соловьев и stone :
Дело тут вот в чем: Сначала у меня отображается в гриде одна таблица - справочник ( около 10 000 записей) иногда для этой таблицы включают фильтры (остается 5000 - 20 записей в зависимости от фильтра)
и надо чтоб эта таблица была винда юзеру всё время и сортировку юзер меняет по разным полям когда захочет и поиск по таблице также иногда хочет делать опять же по разным полям, и ему надо чтоб отображалось не только это одно найденное поле но все соседние (для этого и использую Find, подключая различные индексы в зависимости от нужного поля)
а потом, когда эзер выберет нужную строчку (ткнет мышкой например), по ней выдается информация из других таблиц (вот тут я использую селект)
Если я буду использовать в первом случае Квери, то как мне сделать контекстный поиск?
по индексам это просто - делаю Find и курсор встает на нужную строчку (позиционирование происходит при каждом нажатии клавиши, по стольким буквам, сколько набрали)
а с квери как делать?
только не говорите про like - он мне отрежет все строчки что не удовлетворяет условию, а мне надо только чтоб он их пережвинул и можно было вернуться прокрутив ролик....
если это не вопрос а уход от решения, предложи реальное решение,
я просто не могу придумать... ;)
А в своей правоте я не уверен конечно, просто привожу различные аргументы и жду их подтверждения или опровержения.
← →
Соловьев (2003-04-17 15:05) [14]узнать у юзера как ему удается обработать 10 000 записей...
← →
zom (2003-04-17 15:17) [15]да юзер эти записи не обрабатывет...
это просто справочник товара (ну нормально когда в магазинчике 10 тыс наменований - певерь это совсем не много) и юзер из них выбирает - либо ограничивает выбор группой или даже подгруппой товаров, а может и по всему списку искать по названию (или по артиклу или по цене) т.к. группы и подгруппы могут быть перепутаны или не понятны глупому кассиру
и он хочет видеть все похожие соседние (ну не знает как пишется "Молоко Козье" или "Молоко Козиное" )
так что приходится давать юзверям как можно больше возможностей
вот мне бы и хотелось узнать по-больше вариантов реализации такой задачи и сравнить их на практике....
← →
Соловьев (2003-04-17 15:25) [16]
> т.к. группы и подгруппы могут быть перепутаны
вот тут-то ты и должен подумать, а почему они перепутаны? сделай такую структуру чтобы не путались. Почитай про юзабилити. Как сделать так чтобы юзер мог с наименьшими ошибками бродить по этим групам.
← →
zom (2003-04-17 16:12) [17]про юзабилити я почитал... интересно... но на практике так не всегда получается хорошо...
ну группы я сделал древовидные (глубиной до трех) и TTreeView использую для их отображения, но новый товар заводят разные люди, и они могут назначить для него нету группу... или кассир будет искать не в той, так что им сказано - если не находите в группе - ищите по всему товару.
← →
Соловьев (2003-04-17 16:19) [18]
> но новый товар заводят разные люди, и они могут назначить
> для него нету группу...
сделать так что могли назначить ту. Например создать групу для товаров в которых эти люди сомниваются - т.е. к какой группе их отнести. завести товар в эту группу. И если кассир не находит в той что по идее должно быть, исчет в той дополнительной.
← →
zom (2003-04-17 16:34) [19]да я так и сделал - там есть группы групп и т.д.
и есть еще группа 0 - "Всё остальное", в которой по норме должно быть пусто...
Страницы: 1 вся ветка
Форум: "Базы";
Текущий архив: 2003.05.08;
Скачать: [xml.tar.bz2];
Память: 0.5 MB
Время: 0.015 c