Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Алгоритм поиска
|
|||
|---|---|---|---|
|
#18+
Поделитесь пожалуйста как бы Вы поступили (в смысле разработки алгоритма) если нужно было организовать комплексный запрос к 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 при этом обработка запроса выполняется долго В связи с этим такой вопрос не изменяя имеющиеся индексы как организовать быстрый поиск и возможно ли такое Заранее благодарю Рам ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.06.2004, 08:22 |
|
||
|
Алгоритм поиска
|
|||
|---|---|---|---|
|
#18+
Хм, я весь код детально не изучал (слишком много и путано), но навскидку настораживает то, что у Вас данные выбираются в курсоры и дальнейший поиск ведется по этим курсорам (так мне показалось). Естественно, индексы таблиц при этом на поиск никак не влияют... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.06.2004, 09:20 |
|
||
|
Алгоритм поиска
|
|||
|---|---|---|---|
|
#18+
Ну и наделано индексов! Целый зоопарк ;-) А самое печальное, что все это богатство не используется. :( Вот есть у тебя индекс 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ом надо, как минимум, обрамить. Таблица же розыска лиц - тоже весьма нехилого размера - вообще индексов не имеет. Наблюдаем две крайности. Делать индексы надо, но с умом, не более чем необходимо. И оптимизировать запросы надо. И будет все летать ;-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.06.2004, 09:39 |
|
||
|
Алгоритм поиска
|
|||
|---|---|---|---|
|
#18+
Дело в том что эти индексы не я составил и трогать их я немогу Они используются другой программой Мне нужно составить свою программу поиска не изменяя структуру индексов баз ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.06.2004, 09:50 |
|
||
|
Алгоритм поиска
|
|||
|---|---|---|---|
|
#18+
У базы розыска тоже есть индексы ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.06.2004, 10:11 |
|
||
|
Алгоритм поиска
|
|||
|---|---|---|---|
|
#18+
Никто не мешает: 1) создавать и удалять собственные временные индексные файлы 2) если уж необходимо работать с курсорами, индексировать эти курсоры, или лучше таблицы. А так индексы при поиске не работают... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.06.2004, 10:19 |
|
||
|
Алгоритм поиска
|
|||
|---|---|---|---|
|
#18+
На создание своих временных индексов разве не будет затрачиватся дополнительное время Создавать для каждого запроса временные индексы не приведет к увеличению времени выполнения запроса? Или я не понял ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.06.2004, 10:23 |
|
||
|
Алгоритм поиска
|
|||
|---|---|---|---|
|
#18+
Почитай статью по индексам http://www.foxclub.ru/kb/index.php?sid=29869&aktion=artikel&rubrik=004&id=57&lang=ru Там много интересного. Например, индексы имебщие FOR-условие вообще не используются в Rushmore-оптимизации. Т.е. на скорость поиска никак не влияют. Поиск по LIKE (если подразумевается, что искомое значение может быть в любом месте строки) вообще не поддается оптимизации. Т.е. это будет заведомо очень медленная операция Далеко не всегда, использование Select-SQL предпочтительнее с точки зрения быстродействия перед прямым сканированием таблиц (SCAN...ENDSCAN). Это надо проверять в каждом конкретном случае. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.06.2004, 10:35 |
|
||
|
Алгоритм поиска
|
|||
|---|---|---|---|
|
#18+
Ага, я неправильно понял идею, сорри, надо было просто внимательнее посмотреть :) Так вроде индексы необходимые все есть. Лишних куча, но это как я понимаю не страшно. Я бы для начала поделил код на части и посмотрел в каком месте тормоза. Так-то несколько миллионов записей, десяток ЛАЙКов, и быстрый поиск - скорее всего нереально. Как вариант, ЛАЙКи можно натравливать не одновременно, а по одному, возможно получится быстрее. То есть если AND - натравливается первый ЛАЙК, потом на получившуюся выборку - второй и т.д. А если OR - получаем по одному курсору для каждого ЛАЙКа, оъединяем курсоры. По идее может дать заметное ускорение при небольшом количестве записей в выборках.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.06.2004, 10:39 |
|
||
|
Алгоритм поиска
|
|||
|---|---|---|---|
|
#18+
На создание своих временных индексов разве не будет затрачиватся дополнительное время? Будет. Но их (даже вместе с копией таблицы, структуру которой можно оптимизировать именно для поиска) можно создавать не перед каждым поиском, а реже. Например, раз в день. Конечно, это плохо, потому что некоторые, самые свежие данные не попадут в выборку. Но мое мнение таково: самые лучшие программы, как правило, являются самыми лучшими компромиссами. Создавать для каждого запроса временные индексы не приведет к увеличению времени выполнения запроса? Зависит от многих факторов. Проверяется практически. Из моей практики, в очень многих случаях время на создание временного индекса будет меньше, чем ускорение запроса вследствие его применения. Т.е. в конечном итоге мы выигрываем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.06.2004, 10:56 |
|
||
|
Алгоритм поиска
|
|||
|---|---|---|---|
|
#18+
Статью конечно я уже прочитал. Спасибо Вот мне нужно примерно сделать выборку по полю А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 и это хорошо при поиске на строгое соответствие,а как быть при использовании '%' и '_' Здесь даже не знаю что делать ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.06.2004, 11:08 |
|
||
|
Алгоритм поиска
|
|||
|---|---|---|---|
|
#18+
Неужели ни у кого не было такой задачи Что-то не верится Слышал что такую технологию поиска где-то реализовали и у них поиск по таким большим базам (всего 6 баз с общим объемом 7-9 млн записей) и запрос выполняется в самом сложном случае до минуты ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.06.2004, 11:15 |
|
||
|
Алгоритм поиска
|
|||
|---|---|---|---|
|
#18+
С таким подходом ускорения не получим. Предлагаю двигаться вот в какую сторону. Если невозможно самое основное выражение поиска сделать оптимизируемым, нужно добавить оптимизируемые второстепенные усекающие условия. Допустим, оптимизируемые условия за пару секунд оставят от нескольких миллионов записей несколько тысяч - а по ним уже и LIKE сравнительно быстро пробежит. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.06.2004, 11:26 |
|
||
|
Алгоритм поиска
|
|||
|---|---|---|---|
|
#18+
Например, так: select * ; from ugon ; where a28 like '%45678' ; and марка = 'Фольксваген' ; and модель = 'Пассат' ; and цвет = 'Зеленый' * (предполагается, что индексы по марке, модели и цвету есть). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.06.2004, 11:30 |
|
||
|
Алгоритм поиска
|
|||
|---|---|---|---|
|
#18+
Команда select * ; from ugon ; where a28 like '%45678' ; (неоптимизируемый) and марка = 'Фольксваген' ;(оптимизируемый) and модель = 'Пассат' ; and цвет = 'Зеленый' выберет фольксвагены зеленого цвета Тогда я не смогу выбрать все записи из базы для которых where a28 like '%45678' ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.06.2004, 11:43 |
|
||
|
Алгоритм поиска
|
|||
|---|---|---|---|
|
#18+
В этой связи SEEK с подключением индексов конечно ищет намного бысрее чем SQL и это хорошо при поиске на строгое соответствие,а как быть при использовании '%' и '_' Здесь даже не знаю что делать Посмотри команду SET EXACT OFF (т.е. поиск по "нестрогому" значению) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.06.2004, 11:53 |
|
||
|
Алгоритм поиска
|
|||
|---|---|---|---|
|
#18+
Есть и другие специальные способы ведения поиска. Например, 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%' По крайней мере, в оптимизированном режиме отсечешь все номера, в которых пятерок меньше двух и нет ни одной семерки. Даст ли это прирост скорости? Неизвестно. Для достаточно длинных подстрок - должно. Это простой вариант оптимизации. Можно предложить гораздо больше наворотов. Суть понятна? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.06.2004, 12:56 |
|
||
|
Алгоритм поиска
|
|||
|---|---|---|---|
|
#18+
Первое решение понятно а второе нереально в данном случае поскольку каждый раз придется создавать в базе угон дополнительное поле и связывать его с технической таблицей Я же не могу вносить изменения в базе угон ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.06.2004, 13:16 |
|
||
|
Алгоритм поиска
|
|||
|---|---|---|---|
|
#18+
Под ugon_id имеется в виду поле или сочетание полей в ugon, которое является первичным ключом этой таблицы. Чтоб на него ссылаться. По идее, вместо ПК можно использовать и то поле, по которому ведем поиск. Т.е. если ищем по регзнаку, используем в качестве ПК таблицы tt тот же самый регзнак ;-) Кстати, так даже и лучше. Только, повторюсь, увеличения производительности при таком подходе можно ждать только если в оптимизированном режиме будет отсечена львиная доля записей. Иначе можем получить даже замедление по сравнению с чистым like. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.06.2004, 14:10 |
|
||
|
Алгоритм поиска
|
|||
|---|---|---|---|
|
#18+
Если всякую фамилию вводим русскими буквами, то всегда ли UPPER(<фамилия>) будет той же фамилией набранной буквами русского алфавита в верхнем регистре? Необходимо ли навязывание пользователю обязательства соблюдать какие-то правила ввода символов, когда этих правил можно избежать? Речь вот о чём. На сколько известно мне, VIN у ВАЗ-а начинается с 'XTA'. Сколько есть способов напечатать это "xta"? Основы комбинаторики дадут вам правильный ответ, конечно, но не дадут ответа на следующий вопрос: а как в таблицу эти данные внесены? Вы, на сколько я понял, не можете изменить данные в таблице, переработав её как следует и приведя данные к какому-то одному соглашению. Потому, извините, вам бы вовсе следовало позабыть про UPPER, когда вы работаете с данными российского происхождения. Я не говорю, что эти данные плохие. Данные, когда они есть, всегда хорошие. Только лень возиться самому и найти то, что необходимо. Кстати, в предложенном ко всеобщему вниманию коде заложена слишком большая вероятность того, что не сыщется то, что было бы надо, когда это необходимое есть, но кто-то тот, кто вводил данные не счёл необходимым соблюдать какие-то правила, рассудив здраво, что все эти правила можно предусмотреть в программной обработке. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2004, 19:33 |
|
||
|
|

start [/forum/topic.php?fid=41&fpage=376&tid=1596436]: |
0ms |
get settings: |
11ms |
get forum list: |
17ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
38ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
70ms |
get tp. blocked users: |
2ms |
| others: | 285ms |
| total: | 445ms |

| 0 / 0 |
