powered by simpleCommunicator - 2.0.60     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / FoxPro, Visual FoxPro [игнор отключен] [закрыт для гостей] / Алгоритм поиска
20 сообщений из 20, страница 1 из 1
Алгоритм поиска
    #32543884
Рам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Поделитесь пожалуйста как бы Вы поступили (в смысле разработки алгоритма) если нужно было
организовать комплексный запрос к 3-5 базам одновременно.

Задача

Имеются следующие базы
1. UGON.dbf-база угнанного ТС около 2 млн. записей с полями и индексами
A1 C 4
A4 C 10
A5 C 1
A6 C 6
A7 C 6
A8 C 6
A9 C 1
A23 C 9 регзнак
A24 C 2
A25 C 20 марка
A26 C 3
A27 C 2
A28 C 20 идентификационный номер
A29 C 20 номер двигателя
A30 C 20 номер шасси
A31 C 20 номер кузова
A32 C 3
A63 C 2
A64 C 6
A65 C 4
A67 C 6

его идексы
A1 tag A1
A23 tag A23
A25 tag A25
A28 tag A28
A29 tag A29
A30 tag A30
A31 tag A31
IIF(LEN(TRIM(A28))>0,SUBSTR(A28,LEN(TRIM(A28)),1),"")+IIF(LEN(TRIM(A28))>1,SUBSTR(A28,LEN(TRIM(A28))-1,1),"")+IIF(LEN(TRIM(A28))>2,SUBSTR(A28,LEN(TRIM(A28))-2,1),"")+IIF(LEN(TRIM(A28))>3,SUBSTR(A28,LEN(TRIM(A28))-3,1),"") tag S476085424 For .NOT.EMPTY(A28)
IIF(LEN(TRIM(A30))>0,SUBSTR(A30,LEN(TRIM(A30)),1),"")+IIF(LEN(TRIM(A30))>1,SUBSTR(A30,LEN(TRIM(A30))-1,1),"")+IIF(LEN(TRIM(A30))>2,SUBSTR(A30,LEN(TRIM(A30))-2,1),"")+IIF(LEN(TRIM(A30))>3,SUBSTR(A30,LEN(TRIM(A30))-3,1),"") tag S476085436 For .NOT.EMPTY(A30)
IIF(LEN(TRIM(A31))>0,SUBSTR(A31,LEN(TRIM(A31)),1),"")+IIF(LEN(TRIM(A31))>1,SUBSTR(A31,LEN(TRIM(A31))-1,1),"")+IIF(LEN(TRIM(A31))>2,SUBSTR(A31,LEN(TRIM(A31))-2,1),"")+IIF(LEN(TRIM(A31))>3,SUBSTR(A31,LEN(TRIM(A31))-3,1),"") tag S476085382 For .NOT.EMPTY(A31)
SUBSTR(A29,2) tag A29_2 For .NOT.EMPTY(SUBSTR(A29,2))
SUBSTR(A29,3) tag A29_3 For .NOT.EMPTY(SUBSTR(A29,3))
SUBSTR(A29,4) tag A29_4 For .NOT.EMPTY(SUBSTR(A29,4))
SUBSTR(A29,5) tag A29_5 For .NOT.EMPTY(SUBSTR(A29,5))
SUBSTR(A29,6) tag A29_6 For .NOT.EMPTY(SUBSTR(A29,6))
SUBSTR(A29,7) tag A29_7 For .NOT.EMPTY(SUBSTR(A29,7))
SUBSTR(A29,8) tag A29_8 For .NOT.EMPTY(SUBSTR(A29,8))
SUBSTR(A29,9) tag A29_9 For .NOT.EMPTY(SUBSTR(A29,9))
SUBSTR(A29,10) tag A29_10 For .NOT.EMPTY(SUBSTR(A29,10))
SUBSTR(A29,11) tag A29_11 For .NOT.EMPTY(SUBSTR(A29,11))
SUBSTR(A29,12) tag A29_12 For .NOT.EMPTY(SUBSTR(A29,12))
SUBSTR(A29,13) tag A29_13 For .NOT.EMPTY(SUBSTR(A29,13))
SUBSTR(A29,14) tag A29_14 For .NOT.EMPTY(SUBSTR(A29,14))
SUBSTR(A29,15) tag A29_15 For .NOT.EMPTY(SUBSTR(A29,15))
SUBSTR(A29,16) tag A29_16 For .NOT.EMPTY(SUBSTR(A29,16))
SUBSTR(A29,17) tag A29_17 For .NOT.EMPTY(SUBSTR(A29,17))
SUBSTR(A29,18) tag A29_18 For .NOT.EMPTY(SUBSTR(A29,18))
SUBSTR(A29,19) tag A29_19 For .NOT.EMPTY(SUBSTR(A29,19))
A4 tag A4
----------------------------------------------------------------------------------------------------------------
2.UDOK_FED.dbf-база утраченной спецпродукции 5,5 млн записей

RIR C 4
VUCN C 1
DATAPU C 6
DATAARX C 6
REZROZ C 1
KODOBJ C 2
KODTIPZN C 2
CERIA C 4 серия
INPNOM C 8 начальный номер
OUTNOM C 8 конечный номер
KODDOPSVEDC 2
REGOUT C 4
DATAOUT C 6
REGOBNAR C 4
TEXOPER C 2
DATAOPER C 6
USER C 4
TEL_REG C 11
PODR_INIC C 3

его индексы

CERIA-INPNOM tag SERNOM
CERIA tag CERIA
inpnom tag inpnom

3.KL.dbf база розыска лиц около 200000 записей

P0 C 9
P1 C 3
P2 C 3
P3 C 3
P4 C 3
P5 C 36 фамилия
P6 C 20 имя
P7 C 20 отчество
P8 C 4
P9 C 24
P10 C 8 Дата рождения
P11 C 24
P12 C 24
P13 C 30
P14 C 36
P15 C 16 паспорт
P16 C 18
P17 C 8
P18 C 60
P19 C 24
P20 C 30
P21 C 36
P22 C 65

далее я сделал форму на котором нужно вводить
данные

и написал примерно такой код

SET DEFAULT TO c:\PROB\SPR\
USE UGON IN 0 ORDER a1
USE udok_fed in 0
USE kl IN 0
*Здесь открываются справочники
USE sregion IN 0 ORDER a1
USE VU IN 0 ORDER a5
USE REZROZ IN 0 ORDER a9
USE SPRCVET IN 0 ORDER a32
USE TEXNOP IN 0 ORDER a63

USE dopsved IN 0 ORDER koddopsved
USE VU_dok IN 0 ORDER vucn
USE znak IN 0 ORDER kodtipzn
USE doc_spr IN 0 ORDER kodobj
USE dregion IN 0 ORDER rir
USE rezdok IN 0 ORDER rezroz
USE texdok IN 0 ORDER texoper


LOCAL zap
*OPEN DATABASE zapros
*USE dataz IN 0
*thisform.zpinsert()
WITH THISFORM.PAgeframe1.PAge1
IF .NOT. EMPTY(.Txtznak.Value+.Txtmarka.Value+.Txtvin.Value+.Txtback.Value+.Txtkyz.Value+.Txtshassi.Value)
sele ugon
zap11='select * from ugon into table tmpug'
IL='AND'
ZAP2=''


IF .NOT. EMPTY(.txtznak.VALUE)
ZAP2=ZAP2+IL+' A23 LIKE'+" '"+upper(alltrim(.txtznak.VALUE))+"'"+' '
ENDIF
IF .NOT. EMPTY(.txtmarka.VALUE)
ZAP2=ZAP2+IL+' A25 LIKE'+" '"+upper(alltrim(.txtmarka.VALUE))+"'"+' '
ENDIF
IF .NOT. EMPTY(.txtvin.VALUE)
ZAP2=ZAP2+IL+' A28 LIKE'+" '"+upper(alltrim(.txtvin.VALUE))+"'"+' '
ENDIF
IF .NOT. EMPTY(.txtback.VALUE)
ZAP2=ZAP2+IL+' A29 LIKE'+" '"+upper(alltrim(.txtback.VALUE))+"'"+' '
ENDIF
IF .NOT. EMPTY(.txtkyz.VALUE)
ZAP2=ZAP2+IL+' A30 LIKE'+" '"+upper(alltrim(.txtkyz.VALUE))+"'"+' '
ENDIF
IF .NOT. EMPTY(.txtshassi.VALUE)
ZAP2=ZAP2+IL+' A31 LIKE'+" '"+upper(alltrim(.txtshassi.VALUE))+"'"+' '
ENDIF
IF .NOT. EMPTY(ZAP2)
ZAP2=SUBSTR(ZAP2,1,LEN(ZAP2)-1)
ZAP2=SUBSTR(ZAP2,5,LEN(ZAP2))
WAIT WINDOW ZAP2
ENDIF
ZAP=zap11+' WHERE '+ZAP2
&zap
SET RELATION TO a1 INTO sregion IN tmpug additive
SET RELATION TO a5 INTO VU IN tmpug additive
SET RELATION TO a9 INTO REZROZ IN tmpug additive
SET RELATION TO a32 INTO SPRCVET IN tmpug additive
SET RELATION TO a63 INTO TEXNOP IN tmpug additive
IF RECCOUNT()>0
THISFORM.PAGEFRAME1.PAGES(2).Enabled=.T.
endif
ENDIF
IF .NOT. EMPTY(.Txtznak.Value+.Txtptc.Value+.Txtdoc.Value+.txtvodit.value)

ZAP1='select * from UDOK_fed into cursor mmUDOK noconsole '
IL='OR'
ZAP2=''

IF .NOT. EMPTY(.txtznak.VALUE)
ZAP2=ZAP2+IL+' (INPNOM+CERIA) LIKE'+" '"+upper(alltrim(.txtznak.VALUE))+"'"+' '
ENDIF
IF .NOT. EMPTY(.txtptc.VALUE)
ZAP2=ZAP2+IL+' (CERIA+INPNOM) LIKE'+" '"+upper(alltrim(.txtptc.VALUE))+"'"+' '
ENDIF
IF .NOT. EMPTY(.txtdoc.VALUE)
ZAP2=ZAP2+IL+' (CERIA+INPNOM) LIKE'+" '"+upper(alltrim(.txtdoc.VALUE))+"'"+' '
ENDIF
IF .NOT. EMPTY(.txtvodit.VALUE)
ZAP2=ZAP2+IL+' (CERIA+INPNOM) LIKE'+" '"+upper(alltrim(.txtvodit.VALUE))+"'"+' '
ENDIF
IF .NOT. EMPTY(ZAP2)
ZAP2=SUBSTR(ZAP2,1,LEN(ZAP2)-1)
ZAP2=SUBSTR(ZAP2,4,LEN(ZAP2))
ENDIF
ZAP=ZAP1+'WHERE'+ZAP2
WAIT WINDOW ZAP
&ZAP
SET RELATION TO VUCN INTO vu_dok IN mmudok additive
SET RELATION TO kodtipzn INTO znak IN mmudok additive
SET RELATION TO koddopsved INTO dopsved IN mmudok additive
SET RELATION TO kodobj INTO doc_spr IN mmudok additive
SET RELATION TO rir INTO dregion IN mmudok additive
SET RELATION TO rezroz INTO rezdok IN mmudok additive
SET RELATION TO texoper INTO texdok IN mmudok additive

IF RECCOUNT()>0
THISFORM.PAGEFRAME1.PAGES(3).Enabled=.T.
endif
ENDIF
*здесь исправления не внесены
IF .NOT. EMPTY(.Txtfam.Value+.Txtname.Value+.Txtsurn.Value+.Txtdate.Value+.txtudost.value)
ZAP1='select * from kl into cursor mmkl noconsole '
IL='AND'
ZAP2=''
IF FILE('SQL.PRG')
erase sql.prg
erase sql.fxp
gnErrFile = FCREATE('SQL.PRG')
*('SQL.PRG',12)
ELSE
gnErrFile = FCREATE('SQL.PRG')
ENDIF
IF .NOT. EMPTY(.txtfam.VALUE)
ZAP2=ZAP2+IL+' p5 LIKE'+" '"+upper(alltrim(.txtfam.VALUE))+"'"+' '
ENDIF
IF .NOT. EMPTY(.txtname.VALUE)
ZAP2=ZAP2+IL+' p6 LIKE'+" '"+upper(alltrim(.txtname.VALUE))+"'"+' '
ENDIF
IF .NOT. EMPTY(.txtsurn.VALUE)
ZAP2=ZAP2+IL+' p7 LIKE'+" '"+upper(alltrim(.txtsurn.VALUE))+"'"+' '
ENDIF
IF .NOT. EMPTY(.txtdate.VALUE)
ZAP2=ZAP2+IL+' p10 LIKE'+" '"+upper(alltrim(.txtdate.VALUE))+"'"+' '
ENDIF
IF .NOT. EMPTY(.txtudost.VALUE)
ZAP2=ZAP2+IL+' p15 LIKE'+" '"+upper(alltrim(.txtudost.VALUE))+"'"+' '
ENDIF
IF .NOT. EMPTY(ZAP2)
ZAP2=SUBSTR(ZAP2,1,LEN(ZAP2)-1)
ZAP2=SUBSTR(ZAP2,4,LEN(ZAP2))
ENDIF
ZAP=ZAP1+'WHERE'+ZAP2
WAIT WINDOW ZAP
FWRITE(gnErrFile, ZAP)
FCLOSE(gnErrFile)
DO SQL
IF RECCOUNT()>0
THISFORM.PAGEFRAME1.PAGES(4).Enabled=.T.
endif
ENDIF
ENDWITH

при этом обработка запроса выполняется долго
В связи с этим такой вопрос не изменяя имеющиеся индексы
как организовать быстрый поиск и возможно ли такое

Заранее благодарю

Рам
...
Рейтинг: 0 / 0
Алгоритм поиска
    #32543960
Раз (1)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Хм, я весь код детально не изучал (слишком много и путано), но навскидку настораживает то, что у Вас данные выбираются в курсоры и дальнейший поиск ведется по этим курсорам (так мне показалось). Естественно, индексы таблиц при этом на поиск никак не влияют...
...
Рейтинг: 0 / 0
Алгоритм поиска
    #32543980
Urri
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ну и наделано индексов! Целый зоопарк ;-)

А самое печальное, что все это богатство не используется. :(

Вот есть у тебя индекс SUBSTR(A29,10) tag A29_10 For .NOT.EMPTY(SUBSTR(A29,10))

А ищешь так:
where a29 like ...

Чтоб индекс использовался, в левой части выражения сравнения в where должно быть то же самое, что и в выражении индекса. Например, если точно знаем, что надо искать десятый знак, надо искать именно так:

where SUBSTR(A29,10) = ...

Потом, всякие там индексы с for-условием. Не хочешь иметь много проблем с падением индексов - не используй в них фразу for (тем более, что в where-условие запроса включить похожее ограничение все равно придется).

Теги S476085424 и подобные ему, вероятно, нужны только для организации какой-то сортировки в форме? Выбрасывай их! Кстати, они ненормальные не только из за того, что в левой части оператора сравнения такую конструкцию не воспроизвести никогда, и не только потому, что там есть условие for, но и потому, что индексировать надо по строкам постоянной от записи к записи длины. Все IIFы еще PADRом надо, как минимум, обрамить.

Таблица же розыска лиц - тоже весьма нехилого размера - вообще индексов не имеет.

Наблюдаем две крайности. Делать индексы надо, но с умом, не более чем необходимо. И оптимизировать запросы надо. И будет все летать ;-)
...
Рейтинг: 0 / 0
Алгоритм поиска
    #32544001
РАМ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Дело в том что эти индексы не я составил и трогать их я немогу
Они используются другой программой
Мне нужно составить свою программу поиска не изменяя структуру индексов
баз
...
Рейтинг: 0 / 0
Алгоритм поиска
    #32544055
Рам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
У базы розыска тоже есть индексы
...
Рейтинг: 0 / 0
Алгоритм поиска
    #32544086
Раз (1)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Никто не мешает:
1) создавать и удалять собственные временные индексные файлы
2) если уж необходимо работать с курсорами, индексировать эти курсоры, или лучше таблицы.

А так индексы при поиске не работают...
...
Рейтинг: 0 / 0
Алгоритм поиска
    #32544098
РАМ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
На создание своих временных индексов разве не будет затрачиватся
дополнительное время
Создавать для каждого запроса временные индексы не приведет к увеличению времени выполнения запроса?
Или я не понял
...
Рейтинг: 0 / 0
Алгоритм поиска
    #32544135
Фотография ВладимирМ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Почитай статью по индексам

http://www.foxclub.ru/kb/index.php?sid=29869&aktion=artikel&rubrik=004&id=57&lang=ru

Там много интересного. Например, индексы имебщие FOR-условие вообще не используются в Rushmore-оптимизации. Т.е. на скорость поиска никак не влияют.

Поиск по LIKE (если подразумевается, что искомое значение может быть в любом месте строки) вообще не поддается оптимизации. Т.е. это будет заведомо очень медленная операция

Далеко не всегда, использование Select-SQL предпочтительнее с точки зрения быстродействия перед прямым сканированием таблиц (SCAN...ENDSCAN). Это надо проверять в каждом конкретном случае.
...
Рейтинг: 0 / 0
Алгоритм поиска
    #32544154
Раз (1)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ага, я неправильно понял идею, сорри, надо было просто внимательнее посмотреть :)

Так вроде индексы необходимые все есть. Лишних куча, но это как я понимаю не страшно.
Я бы для начала поделил код на части и посмотрел в каком месте тормоза.

Так-то несколько миллионов записей, десяток ЛАЙКов, и быстрый поиск - скорее всего нереально.

Как вариант, ЛАЙКи можно натравливать не одновременно, а по одному, возможно получится быстрее. То есть если AND - натравливается первый ЛАЙК, потом на получившуюся выборку - второй и т.д. А если OR - получаем по одному курсору для каждого ЛАЙКа, оъединяем курсоры. По идее может дать заметное ускорение при небольшом количестве записей в выборках....
...
Рейтинг: 0 / 0
Алгоритм поиска
    #32544216
Urri
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
На создание своих временных индексов разве не будет затрачиватся
дополнительное время?
Будет. Но их (даже вместе с копией таблицы, структуру которой можно оптимизировать именно для поиска) можно создавать не перед каждым поиском, а реже. Например, раз в день. Конечно, это плохо, потому что некоторые, самые свежие данные не попадут в выборку. Но мое мнение таково: самые лучшие программы, как правило, являются самыми лучшими компромиссами.

Создавать для каждого запроса временные индексы не приведет к увеличению времени выполнения запроса?
Зависит от многих факторов. Проверяется практически. Из моей практики, в очень многих случаях время на создание временного индекса будет меньше, чем ускорение запроса вследствие его применения. Т.е. в конечном итоге мы выигрываем.
...
Рейтинг: 0 / 0
Алгоритм поиска
    #32544268
РАМ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Статью конечно я уже прочитал.
Спасибо

Вот мне нужно примерно сделать выборку по полю А28

select * from ugon where a28 like '%45678' (c % и без него)
Я могу программно распознать нужно использовать LIKE или нет и соответственно выполнить один из двух команд

select * from ugon where a28 like '%45678'
или
select * from ugon where a28 = '45678' (в случае строгого соответствия)
но и эти одиночные запросы выполняются долго
Попробовал выполнить их и отключив индексы
set order to
тоже самое
Далее мне кажется что вы не совсем поняли мою задачу
Так при запросе я должен заносить значения для поиска либо на строгое соответствие либо с использованием символов '%' и '_'
В этой связи SEEK с подключением индексов конечно ищет намного бысрее чем SQL и это хорошо при поиске на строгое соответствие,а как быть при использовании '%' и '_' Здесь даже не знаю что делать
...
Рейтинг: 0 / 0
Алгоритм поиска
    #32544291
РАМ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Неужели ни у кого не было такой задачи
Что-то не верится
Слышал что такую технологию поиска где-то реализовали и у них поиск по таким большим базам (всего 6 баз с общим объемом 7-9 млн записей) и запрос выполняется в самом сложном случае до минуты
...
Рейтинг: 0 / 0
Алгоритм поиска
    #32544330
Urri
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
С таким подходом ускорения не получим.
Предлагаю двигаться вот в какую сторону.
Если невозможно самое основное выражение поиска сделать оптимизируемым, нужно добавить оптимизируемые второстепенные усекающие условия. Допустим, оптимизируемые условия за пару секунд оставят от нескольких миллионов записей несколько тысяч - а по ним уже и LIKE сравнительно быстро пробежит.
...
Рейтинг: 0 / 0
Алгоритм поиска
    #32544347
Urri
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Например, так:

select * ;
from ugon ;
where a28 like '%45678' ;
and марка = 'Фольксваген' ;
and модель = 'Пассат' ;
and цвет = 'Зеленый'
* (предполагается, что индексы по марке, модели и цвету есть).
...
Рейтинг: 0 / 0
Алгоритм поиска
    #32544382
РАМ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Команда
select * ;
from ugon ;
where a28 like '%45678' ; (неоптимизируемый)
and марка = 'Фольксваген' ;(оптимизируемый)
and модель = 'Пассат' ;
and цвет = 'Зеленый'
выберет фольксвагены зеленого цвета

Тогда я не смогу выбрать все записи из базы для которых
where a28 like '%45678'
...
Рейтинг: 0 / 0
Алгоритм поиска
    #32544408
alexFV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
В этой связи SEEK с подключением индексов конечно ищет намного бысрее чем SQL и это хорошо при поиске на строгое соответствие,а как быть при использовании '%' и '_' Здесь даже не знаю что делать

Посмотри команду SET EXACT OFF (т.е. поиск по "нестрогому" значению)
...
Рейтинг: 0 / 0
Алгоритм поиска
    #32544542
Urri
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Есть и другие специальные способы ведения поиска.
Например,
1.
where x like '%y%' - не оптимизируется, тогда как
where x = 'y' - при выключенных (off) set exact и set ansi аналог where x like 'y%' - оптимизируется.
Это поможет, если номер начинается с искомой подстроки.

2.
Навскидку. Пусть мы занимаемся оптимизацией поиска по полю a29 таблицы ugon. Пусть также известно, что ПК в ugon - поле ugon_id.
Сооруди техническую таблицу (tt), приспособленную специально для поиска по твоему номеру. Пусть, например, ты знаешь, что в номере могут быть только цифры. Тогда в tt должно быть поле ссылки на таблицу ugon (ugon_ID) и 10 числовых полей:
f1..f0. По каждому из 11 полей - индекс.
При заведении в ugon записи с кодом 1 и номером 00005758, создавай в технической таблице запись
ugon_ID = 1, f0=4, f5=2, f7=1, f8=1

Пусть ищешь подстроку 575.
И сделай (динамически, конечно, можно, а можно и с помощью переменных):
select ugon.* from ugon,tt ;
where ugon.ugon_id=tt.ugon_id;
and tt.f5>=2 ;
and tt.f7>=1 ;
and ugon.a29 like '%575%'

По крайней мере, в оптимизированном режиме отсечешь все номера, в которых пятерок меньше двух и нет ни одной семерки. Даст ли это прирост скорости? Неизвестно. Для достаточно длинных подстрок - должно. Это простой вариант оптимизации. Можно предложить гораздо больше наворотов. Суть понятна?
...
Рейтинг: 0 / 0
Алгоритм поиска
    #32544591
рам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Первое решение понятно а
второе нереально в данном случае
поскольку каждый раз придется создавать в базе угон дополнительное поле и связывать его с технической таблицей
Я же не могу вносить изменения в базе угон
...
Рейтинг: 0 / 0
Алгоритм поиска
    #32544756
Urri
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Под ugon_id имеется в виду поле или сочетание полей в ugon, которое является первичным ключом этой таблицы. Чтоб на него ссылаться. По идее, вместо ПК можно использовать и то поле, по которому ведем поиск. Т.е. если ищем по регзнаку, используем в качестве ПК таблицы tt тот же самый регзнак ;-) Кстати, так даже и лучше.
Только, повторюсь, увеличения производительности при таком подходе можно ждать только если в оптимизированном режиме будет отсечена львиная доля записей. Иначе можем получить даже замедление по сравнению с чистым like.
...
Рейтинг: 0 / 0
Алгоритм поиска
    #32549706
Если всякую фамилию вводим русскими буквами, то всегда ли UPPER(<фамилия>) будет той же фамилией набранной буквами русского алфавита в верхнем регистре?
Необходимо ли навязывание пользователю обязательства соблюдать какие-то правила ввода символов, когда этих правил можно избежать? Речь вот о чём. На сколько известно мне, VIN у ВАЗ-а начинается с 'XTA'. Сколько есть способов напечатать это "xta"? Основы комбинаторики дадут вам правильный ответ, конечно, но не дадут ответа на следующий вопрос: а как в таблицу эти данные внесены?
Вы, на сколько я понял, не можете изменить данные в таблице, переработав её как следует и приведя данные к какому-то одному соглашению. Потому, извините, вам бы вовсе следовало позабыть про UPPER, когда вы работаете с данными российского происхождения. Я не говорю, что эти данные плохие. Данные, когда они есть, всегда хорошие. Только лень возиться самому и найти то, что необходимо.
Кстати, в предложенном ко всеобщему вниманию коде заложена слишком большая вероятность того, что не сыщется то, что было бы надо, когда это необходимое есть, но кто-то тот, кто вводил данные не счёл необходимым соблюдать какие-то правила, рассудив здраво, что все эти правила можно предусмотреть в программной обработке.
...
Рейтинг: 0 / 0
20 сообщений из 20, страница 1 из 1
Форумы / FoxPro, Visual FoxPro [игнор отключен] [закрыт для гостей] / Алгоритм поиска
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]