Что лучше , filter или locate ?

← →
Grey (2003-03-14 11:29) [0]

Сначала использовал в запросах locate для выбора нужной записи, но ввиду больших тормозов перешёл на фильтр , тормоза исчезли, но приятель говорит , что использование фильтров не есть хорошо, потому что на слабых машинах будет жутко тормозить, т.к. якобы фильтр проходит все записи и проверяет на удовлетворению условий причем все это на стороне клиента, чем больше записей и медленней комп тем хуже.
Рассудите нас пожалуйста, Мастера.

← →
Anatoly Podgoretsky (2003-03-14 11:35) [1]

Ты путаешь апельчины с ананасами
Первое это поиск, а второе фильтрация и они никак не связаны по функциональности.
И то и другое проходит по записям, и то и другое делается на клиенте, и то и другое может тормозить, и то и другое зависит от скорости компьютера, количества памяти.
Для выбора нужной записи надо использовать Select * from table where условие, вот это будет делаться на сервере и будет работать быстро.

Вам обоим в книжный магазин за книгами, только потом включать компьютер. :-)

← →
Grey (2003-03-14 11:51) [2]

>Anatoly Podgoretsky

Знаю я что locate это поиск, а filter фильтрация и они никак не связаны по функциональности, главное - что результат получается одинаковый , что с filter , что с locate.

Думаю, что Select * from table where условие тоже будет тормозить , т.к. это используется в OnCalcFields и если постоянно открывать/закрывать запрос, то будет ещё тормознее.

Попутный вопрос:
Правда, что чтобы получить запись , используя фильтр, нужно все записи просмотреть, а lоcate бежит по индексу до нужной (т.е. как бы быстрее) ?

Кстати ошибся в наборе БД, БД - не MySQL, а MSSQL.

← →
Anatoly Podgoretsky (2003-03-14 12:00) [3]

Результат никак не может получаться одинаковым, абсолютно никак.
Настоятельно советую в магизин.
Неправда в общем, но может быть правда для MySQL
Опять фильтрация и перемещение курсора абсолютно ортогональные вещи как по внешнему результату так и назначению.
Lоcate можешь применить к перемещению курсора на отфильтрованной таблице, обратное дикий абсурд.

MSSQL - одназначно SELECT WHERE в ответ одну и только одну запись, ту которую ты бы указал в Lоcate

Применять навигационные методы к реляционным данным, как кто то сказал, это даже не прошлый век, а каменный.

Вам обоим не хватает знания теории.

← →
zacho (2003-03-14 12:01) [4]

> Попутный вопрос:
> Правда, что чтобы получить запись , используя фильтр, нужно
> все записи просмотреть, а lоcate бежит по индексу до нужной
> (т.е. как бы быстрее)

В клиет-серверных СУБД на клиенте ни каких индексов нет ! Соответственно, и Locate работает простым перебором всех записей.

> т.к. это используется в OnCalcFields

Что-то не в порядке у тебя с постановкой задачи. Может тебе нужно тривиальное Master-Detail ?

← →
NickBat (2003-03-14 12:04) [5]

> Anatoly Podgoretsky © (14.03.03 12:00)
> Применять навигационные методы к реляционным данным, как кто то сказал, это даже не прошлый век, а каменный.

Зачем же так категорично? Иногда пользователю гораздо быстрее получить набор данных из 10 записей и потом бегать по ним на своей машине, чем каждый раз заново посылать серверу запрос на выборку ТОЛЬКО одной записи.

← →
NetKnight (2003-03-14 12:10) [6]

Во-первых это разные вещи,
Во-вторых locate - это и есть select <field> from <table> where <condition>
В третьих locate не использует индексы.
В третьих locate - вещь унивирсальная и работает на любой БД (в отличии от FindKey, который использует индексы)

Если интересно, могу кинуть универсальный компонент для поиска в базе слеланый на основе TEdit и использующий самый быстрый метод в зависимоти от БД.

← →
Anatoly Podgoretsky (2003-03-14 12:22) [7]

Если надо получить набор, да пожаулйста, затем по нему можно локально бегать
Первое это фильтр (ограничение выборки), для клиент серверных через Where ...
Второе это перемещение по локальному курсору

NetKnight © (14.03.03 12:10)
Кроме во-первых остальное неверно
Во-вторых locate это никак не то, что ты написал, а перемещение по локальному набору.

В третьих locate использует индексы, если они доступны.

← →
Grey (2003-03-14 12:28) [8]

> zacho ©
Master-Detail не подходит, т.к. OnCalc используется в lookup полях , при изменении поля сразу должен быть виден результат в другом поле

>Anatoly Podgoretsky ©
да знаю я что делает filter и locate
конечно результат в общем не одинаковый , но фильтром я выделяю 1 запись , также как и locate выделяет одну.

Попробую конечно SELECT WHERE , но не думаю, что быстрее будет, надо же на каждую запись будет обращаться к серверу за данными (открывать / закрывать запрос).

← →
zacho (2003-03-14 12:33) [9]

> OnCalc используется в lookup полях

Покажи код этого OnCalc. А то я не понял, что оно делает и зачем это нужно.

← →
NetKnight (2003-03-14 12:42) [10]

--> Anatoly Podgoretsky
Согласен насчёт во-вторых, что-то я наоборот про фильтрацию написал..
И индексы тоже использует... Только что код просмотрел...
Пора врачам сдаваться.. :)

← →
Grey (2003-03-14 12:43) [11]

>zacho ©
Вот код :

procedure TMainForm.InputQueryCalcFields(DataSet: TDataSet); begin wh_01_Order_filter.Filter:="OrgCode="+QuotedStr(InputQuerywh_01_Order_complex_key.Value); wh_01_Order_filter.Filtered := true; InputQueryCustomer_name.Value:=wh_01_Order_filterdcCustomer_name.Value; InputQueryAddress.Value:=wh_01_Order_filterdcCustomerAddress_Address.Value; InputQueryContract.Value:=wh_01_Order_filterdcContract_description.Value; if (not InputQuerywh_01_Order_whGood_ID.IsNull AND not InputQuerywh_01_Order_whPriceList_ID.IsNull) then begin whGoodPrice_filter.Filter:="whGoodPrice_whGood_ID="+InputQuerywh_01_Order_whGood_ID.AsString+ " AND "+ "whGoodPrice_whPriceList_ID="+InputQuerywh_01_Order_whPriceList_ID.AsString; whGoodPrice_filter.Filtered := true; InputQueryprice.Value :=whGoodPrice_filterwhGoodPrice_result_price.Value; end; InputQuerytotal.Value :=InputQueryprice.Value * InputQuerywh_01_Order_quantity.Value; if not InputQuerywh_01_Order_whGood_ID.isNull then begin whGood_filter.Filter:="whGood_ID="+InputQuerywh_01_Order_whGood_ID.AsString; whGood_filter.Filtered :=true; InputQueryGood_name.Value := whGood_filterwhGood_name.Value; InputQuerytotal_with_NDS.Value := InputQuerytotal.Value + InputQuerytotal.Value*0.01*whGood_filterwhGood_NDS_rate.Value; InputQueryNDS_rate.Value := whGood_filterwhGood_NDS_rate.Value; InputQueryweight.Value := whGood_filterwhGood_gross_weight.Value*InputQuerywh_01_Order_quantity.Value; end end;

← →
zacho (2003-03-14 12:48) [12]

Детально в твой код пока не вникал, но у меня сложилось впечатление, что тебе нужны тривиальные lookup поля вместо calculated или join в запросе. И не придется извращаться с locate или фильтром

← →
Grey (2003-03-14 12:53) [13]

← →
zacho (2003-03-14 12:59) [14]

> а мне надо на этапе редактирования

Не совсем понял эту фразу. Напиши конкретней, как тебе надо что бы работало. А чем lookup поля не устраивают ?

← →
Grey (2003-03-14 13:13) [15]

>zacho ©

Не совсем понял эту фразу. Напиши конкретней, как тебе надо что бы работало.

ввожу новую запись , используя lookup поля , когда изменяю данные в lookup поле , перемещаясь по lookupdataset, в другом поле данные должны сразу же изменяться , до сохранения записи,т.е. ввводим в одной колонке в гриде из выпадающего списка 1 , должно подставлять в другую колонку "номер1" из таблицы соответствия
1 "номер 1"
2 "номер 2"
.........

Что лучше , filter или locate ? Найти похожие ветки