Prozradil by pan autor, mistr databáze, mně, pouhému šlendriánskému neprogramátorovi, říci, co je špatné na tom, když uživatel chce např. přes webový formulář najít v tabulce článků o programování všechny, které obsahují třeba slovo 'volatile' nebo třeba podřetězec 'like je na', a co je špatné na tom, když se na to použije LIKE, a jak by to bez LIKE napsal mistr databáze?
ale dobrali. Root ma pocet clanku limutujicich k nule, to by projelo LIKE jedna dve. Krom toho taky lidi tu moc casto asi nevyhledavaji ja tu nevyhledavam ani 1x za mesic.
Přesně od toho je fulltext. Zkuste např. v 3G databázi mailů včetně attachmentů vyhledávat LIKEm. Uživatel může jít na kafe, a skoro totéž mohou udělat všichni ostatní uživatelé daného systému. A to i v express databázi jako je MySQL. Špatné je na tom to, že se sekvenčně čte velká tabulka, což má za následek zahlcení IO, druhak přepíše Vám to obsah cache, a do třetice - pokud se nepoužije sofistikovanější algoritmus a prohledávají se delší texty, tak to utluče i procesor.
v inteligentnich db vam to cache nezahlti ponevadz pokud je velikost tabulky vyrazne vetsi nez velikost buffer cache, tak se jede tablescan nocache prefetch. Podivejte se na execution plan co leze z Oracle nebo db2.
A co kdyz vim, ze v tabulce bude maximalne nekolik desitek zaznamu a text bude dlouhy maximalne nekolik set znaku. To mi taky zahlti IO a utluce procesor? ;-)
tam pak výsledek bude stejný - planner použije sekvenční čtení. Rozdíly začnou být nad 1000 řádků, markantní pak nad 10000 řádků. Pokud mám malý úzký číselník, tak pak bez problémů (pokud nepoužijete ilike).
Ale ja se neptal, jestli se pouzije sekvencni cteni, ale jestli se zahlti IO a CPU.
Takze chcete rict, ze i kdyz mam maly uzky ciselnik (viz moje specifikace vyse), ze pouziti LIKE zahlti IO a CPU??? Nebo je v tomto pripade jeho pouziti bezproblemove?
Odpověděl jsem Vám - planner zvolí sekvenční čtení - z toho plyne stejná zátěž IO a +/- stejná zátěž CPU. Na krátkém řetězci LIKE nebude ani v nejhorším případě extrémně náročný, nicméně porovnávají se řetězce, na druhé straně fulltext bude mít určitou režii s tokenizací, převodem na lexémy, ale pak se porovnávají pouze celá čísla.
PostgreSQL 8.4 umí fultext i na prefixech. Což má pak ještě jednu výhodu. Nevím jestli sledujete stanici Leonardo. Jeden z jejich autorů má příjmení Hora Hořejší. Pak Like 'Hoř%' by Vám nepomohl - uznávám, že se jedná o výjimku. Spíš to uvádím jako ukázku rozvijejících se možností fulltextu, který LIKE částečně eliminuje.
Občas je nutné kombinovat fulltext a LIKE. Fulltext má vyšší selektivitu a pak na vybranou množinu se jako filtr aplikuje LIKE. Pak je to košer.
Vzpomněl jsem si ještě na jeden odstrašující případ. V případě, že máte dohledat například kombinaci tří slov - X, Y, Z .. uživatel do vyhledávacího políčka napíše Praha Soukenicka Smlouva. Takové ty univerzální vyhledávací generující dialogy vyrobí dotaz typu
WHERE
subject ILIKE '%Praha%' AND subject ILIKE '%Soukenicka%' AND subject ILIKE '%Smlouva%' AND body ILIKE '%Praha%' AND body ILIKE '%Soukenicka%' AND body ILIKE '%Smlouva%'
„Zkuste např. v 3G databázi mailů včetně attachmentů vyhledávat LIKEm. Uživatel může jít na kafe“
Soudě podle rychlosti, toto řešení použili v MS Outlooku :-D A to ta schránka měla nějakých ubohých pár set mega, žádné gigabajty :-)