Tebe nuzhen poisk na site-e?
Beresh stroku poiska i explode() - ish ee po probelam ili inym razdelitelyam. posle chego podstavlyaesh poluchennie elementy massiva v sleduyushie zaprosy vmesto token1 i token2
Kak ya ponyal table vyglyadit vot tak
==
CREATE TABLE `Timewind` (`a` VARCHAR(255) NOT NULL, `b` VARCHAR(255) NOT NULL )
==
Esli tebe nado nayti 'token1' i 'token2' to primitivneyshiy nabor zaprosov vyglyadit tak
==
select a from Timewind where a like '%token1%' and a like '%token2%'
==
NAdo naiti zapis' gde est' token1 i net token2
==
select a from Timewind where a like '%token1%' and a not like '%token2%'
==
NU i tak dalee.
Pravda danniy metod ne ochen' khoroshiy, v sluchae bol'shogo kol-va zapisey.....
Gde - to na ~10000 zapisey razmera (255), ne BLOB(*TEXT v tom chisle) vremya otklika na zapros stanet nepriemlimym. Prichina - full table scan. A v sluchae s like ogranichennym procentami s obeikh storon indexy ne ispol'zuyutsya.
Ne zabud' sdelat' limit v kontse zaprosa, chtoby vyvodilis' pervye n elementov. Eto kstati mozhet znachitel'no uvelichit' skorost' otklika na bol'shoy tablitse.
Fil'truy vse simvoly otlichnye ot bukv, tsyfr i defisa.
Postav' ogranichenie na minimal'niy i maximal'niy query string.
Est' eshe neskol'ko bolee krasivykh resheniy.
Poprobuy postroit' slovar'. No mne kazhetsya eto budet slishkom slozhnym v realizacii.
Optimal'nym resheniem mozhet stat' postroenie fulltext index-a. No rabotaet eto delo normal'no tol'ko v vetke 4.0.x, a ona eshe beta. Sam etot mekhanizm vnedren gde to v 3.23.35 ili okolo togo - tochno ne pomnyu. NA sobstvennom opyte znayu, chto spokoyno mozhno ubit' server zakazav postroenie index-a na table s 1.000.000 varchar(255). Da i ne s angliyskimi kodirovkami on rabotaet ne ochen' khorosho.
Khochesh riskovat' - stav' 4.0.3 (samiy posledniy). Ne khochesh rabotay na 3.23.x.
A voobshe kupi kakuyu -to knigu po DBMS.
My favourite "An introduction to database systems" C. J. Date. Ona est' i na russkom.