Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Базы";
Текущий архив: 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
6-23253
ferrik
2003-03-10 20:19
2003.05.08
WinSock


4-23414
stream
2003-03-07 11:46
2003.05.08
сохранение HBITMAP в файл


1-23225
spac
2003-04-25 13:25
2003.05.08
edit


1-23158
shuba
2003-04-24 12:06
2003.05.08
Работа с ресурсами


1-23099
Стрелок
2003-04-24 10:16
2003.05.08
Exe в exe-шнике





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский