Поиск по индексу или 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 - он мне отрежет все строчки что не удовлетворяет условию, а мне надо только чтоб он их пережвинул и можно было вернуться прокрутив ролик....

если это не вопрос а уход от решения, предложи реальное решение,
я просто не могу придумать... ;)

А в своей правоте я не уверен конечно, просто привожу различные аргументы и жду их подтверждения или опровержения.

узнать у юзера как ему удается обработать 10 000 записей...

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

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

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

> т.к. группы и подгруппы могут быть перепутаны

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

про юзабилити я почитал... интересно... но на практике так не всегда получается хорошо...

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

> но новый товар заводят разные люди, и они могут назначить
> для него нету группу...

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

да я так и сделал - там есть группы групп и т.д.
и есть еще группа 0 - "Всё остальное", в которой по норме должно быть пусто...

Поиск по индексу или Select, что быстрее через ADO? Найти похожие ветки