Фильтр по индексным полям

← →
molodoi © (2006-06-13 23:06) [0]

Есть проблема: из таблицы dBase, проиндексированной по нескольким полям (NAME, FNAME, SNAME) нужно выбирать записи по этим полям.
Пока остановился на простой фильтрации, и индекс вобщем-то не при деле. а т.к. кол-во записей переваливает за 500 000, фильтрация не решает проблемы (слишком долго). Помогите советом.
Использование запросов не желательно, хотя если выхода не найдется придется пользоваться ими.

← →
Johnmen © (2006-06-13 23:35) [1]

> Использование запросов не желательно, хотя если выхода не
> найдется придется пользоваться ими.

Это не выход, а СТАНДАРТНОЕ решение.
Впрочем, для любителей тормозов можно и миллион записей на клиента потянуть...:)

← →
Ильш © (2006-06-14 06:13) [2]

> Использование запросов не желательно

конечно нежелательно, зачем эту лажу ваще придумали...

← →
sniknik © (2006-06-14 08:49) [3]

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

а фильтр, можно заменить на setrange (так вроде пишется, мог забыть за давним неиспользованием), он использует индекс, правда фильтр гибче, больше позволяет. но может устроит.

← →
molodoi © (2006-06-18 11:46) [4]

с SetRange все понятно. Только вот фильтрует он по одному полю.
А локальный запрос в самом деле медленнее.

← →
sniknik © (2006-06-18 14:41) [5]

> Только вот фильтрует он по одному полю.
это вряд ли, т.к. в условии передается массив значений... зачем спрашивается, если фильтрует по одному?

← →
molodoi © (2006-06-19 18:17) [6]

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

Нет. массив значений в таком случае как раз и непередается. В этом и вся загвоздка. Каждое последующее значение накладывается на первое, т.е. первое постоянно меняется, и фильтр неполучается.

=====================================

Кстати, кто-нибудь знает аналог запроса CREATE VIEW в Делфях.
Появилась мысль. Используя SetRange, отфильтровываем записи по одному полю. Получаемый набор записей однозначно меньше, и даже если он превышает пару тысяч, все равно остается меньше десятка тысяч. А уж по такому количеству фильтр работает шустрее. Так вот запихиваем этот набор в просмотр и применяем фильтр по оставшимся 2-м полям. Экономим много времени. Плохо то, что мне не известно о такой возможности с просмотром. ПОВТОРЯЮ ИСПОЛЬЗОВАНИЕ ЗАПРОСОВ НЕ ЖЕЛАТЕЛЬНО.
Как вариант можно использовать вторую таблицу, в которую и будем помещать искомый набор, а дальше как описано выше. Сам пока еще не пробовал, но мне думается: это опять скажется на времени, ведь есть разница между 10 и 10 000. Но и тут есть варианты, как переносить записи: можно тупым перебором, можно через массив. Какой из них быстрее - посмотрим.

← →
Sergey13 © (2006-06-19 18:25) [7]

2 [6] molodoi © (19.06.06 18:17)
> Кстати, кто-нибудь знает аналог запроса CREATE VIEW в Делфях.
Так и будет, но... не для указанных тобой БД.

← →
sniknik © (2006-06-19 18:39) [8]

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

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

> Кстати, кто-нибудь знает аналог запроса CREATE VIEW в Делфях.
нет такого, и близко нет. VIEW это в sql сервере, базе/движке есть, но никак не в дельфи.

← →
molodoi © (2006-06-20 12:52) [9]

Приведу пример:

Нужен Петров Николай Васильевич. Строим индекс по трем полям.
Начинаем искать SetRange.
1.Фильтр по фамилии.Берет он первое поле в индексе (здесь это фамилия).
Ищет. Находит.
2.Берет второе поле (имя). Иперестраивает поиск. Т.е. в поле фамилии применяет фильтр по имени и получаем, что в поле фамилии ищется Николай. Хотя он должен искаться в поле имени.
Хорошо. В тексте программы указываем, что надо искать в поле имени, когда ищем это имя. И здесь начинается ерунда типа того, что описано выше. А ошибки нет.

Как организовать фильтр по отфильтрованному? Так будет точнее. но с использованием индексов.

← →
Sergey13 © (2006-06-20 12:56) [10]

> [9] molodoi © (20.06.06 12:52)

У тебя еще не пропало желание заниматься нестандартным сексом вместо того, что бы построить индекс и написать запрос?

← →
sniknik © (2006-06-20 13:11) [11]

> Приведу пример:
это не пример, это художественный вымысел по мотивам какихто (вконец запутанных "прмером") действий...

во первых
> Нужен Петров Николай Васильевич.
если нужет только он - locate, использует индексы если они есть.

> Берет он первое поле в индексе (здесь это фамилия).
ну если берет он то у него и спрашивай почему он их неправильно берет... но мне почемуто кажется что это делаеш ты.

> 2.Берет второе поле (имя).
а вот это уже зачем? задавать, по идее, надо все сразу, потому и передается в функцию массив а не одиночное значение.

> Хорошо. В тексте программы указываем ...
в каком таком тексте???? мы же тут просто треплемся, без всяких текстов.

← →
molodoi © (2006-06-20 16:18) [12]

ривожу отрывок из программы

with Table1 do
begin
IndexName := "Nameidx";
SetRangeStart;
FieldByName("NAME").AsString := "Петров";
FieldByName("FNAME").AsString := "Николай";
FieldByName("SNAME").AsString := "Васильевич";
SetRangeEnd;
FieldByName("NAME").AsString := "Петров";
FieldByName("FNAME").AsString := "Николай";
FieldByName("SNAME").AsString := "Васильевич";
ApplyRange;
end;

Находит Петрова Анатолия Александровича (Алексеевича) и кучу других Петровых среди которых конечно есть Николай Васильевич, но ...

Может я индекс как-то не правильно строю?

Table1.AddIndex("Nameidx",[NAME;FNAME;SNAME],[]);

А?

> ривожу отрывок из программы
> ...
> SetRangeStart;
> ...
вообщето имел в виду, да и говориили после вроде бы о методе setrange... а не самостоятельной "сборке". оно вроде бы тоже самое, но понять знаеш ли трудновато, ты про одно, тебе ответ про другое, хотя вид делают как будто бы про тоже самое.

> Может я индекс как-то не правильно строю?
> Table1.AddIndex("Nameidx",[NAME;FNAME;SNAME],[]);
вполне возможно, может оно так "не понимает", может надо три отдельных, и все их разом указывать (IndexFieldNames)... (?) это проверять надо... а кому охота в уже заброшеных технологиях копаться, без смысла. кому надо, тот и проверяет пускай.

Суть одинаковая. Просто при таком способе насильно указываются поля (да и для наглядности). Пробовал я и SetRange([Edit1.Text...],[Edit1.Text]); тоже самое.

> Суть одинаковая.
суть не сути, а в том, что понять тебя невозможно.

> Пробовал я и SetRange([Edit1.Text...],[Edit1.Text]); тоже самое.
ну, значит не судьба...

Ладно. Похоже дело безнадежное.
Пробовал сегодня создавать запросы. Все работает как надо(индексирование, фильтрация), правда медленно.
Была проблема с кодировкой. Запрос тут не обвинишь - он работает правильно, только вот не понимает имеющуюся кодировку таблицы (она, кстати, "dBase RUS 866"). Пришлось менять ее в Database Desktop на "dBase RUS 866" (нда!) и все нормально заработало: все находит. Один раз, ну два еще можно так менять кодировку, но по 2 раза в день я считаю перебором.

Подскажите как это провернуть программно (смена кодировки таблицы).

← →
Виталий Панасенко (2006-06-21 13:01) [17]

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

В смысле не поддерживает кириллицу? Регистр я тоже соблюдал.

Фильтр по индексным полям Найти похожие ветки