Názory k článku
Princip jednoduchého fulltextu s příklady v SQL a PHP (2)

Jejda...kdyby to tak fungovalo i nad takovymi 50-100 GB dat, to bych to mohl pouzit taky :)

Ad levostranne doplneni: Muzu pouzit SQL wildcards: "LIKE '%lina'". Problem je s indexy, ze...pokud bych potreboval urychlit hledani indexem s zolikem na zacatku, musel bych si ukladat i rotovane slovo. Nicmene pokud rezie zpracovani tabulky slov je dostatecne mala oproti zpracovani tabulky vyskytu, nebude to tak kriticke. (Jeste ze muzeme pracovat ve vazebni tabulce slova<->clanky jen s IDcky :) Jinymi slovy: pri prohledavani narocnem kvuli velkym textum a mnoha clankum spise nez kvuli velkemu poctu dotazu vadi mene nez v opacnem pripade.

Potencialni stop slova? Tipoval bych ta, ktera se vyskytuji v temer kazdem clanku...alias mala selektivita. Proste spocitam procentuelne, kolikrat se slovo "nebo" vyskytuje v clancich a kdyz zjistim, ze v 95%, klidne si ho muzu dovolit vynechat, protoze u funkce relevance zalozene na kvalitativnim hodnoceni (primarni razeni podle poctu ruznych obsazenych slov dotazu) mi moc nepomuze... U jine relevance by mohl byt samozrejme potrebny jiny postup.

Je mozne, ze mi to uz ale poradne nemysli...mel bych jit spat. Vetsi cast domaciho ukolu ted rozhodne dusevne nezvladnu...

Zdravim...
(Kaaczu taky :)

Pokud máte 50-100GB a potřebujete je prohledávat, tak se můžete ozvat nám. Určitě něco vymyslíme :)
»Jyxo

Fakt? Ve Smalltalku a na mem desktopu doma? Nad OODBMS? (protoze v tom bude zbytek SW...)

Kdepak, tohle si radsi udelam sam...ostatne je to i pekne cviceni z lingvistiky, ktera je mym druhym zivotem...

Rikejme tomu hobby :)

V tabulce FT_Index jsem opominul vytvoření indexů nad cizími klíči:
CREATE INDEX FT_Index_IdWord_FK ON FT_Index (IdWord);
CREATE INDEX FT_Index_IdArticle_FK ON FT_Index (IdArticle);

(Příklady budou fungovat i bez nich, ale po naplnění větším objemem dat by se hledání velice zpomalilo.)

Neměl byste ještě nějaké další reference? Tohle mne docela zajímá :)

Opravdu pěkný článek, jsem docela rád že se někdo chytil na můj komentář, že kritizovat umí každý, ale tvořit málokdo a našel se i člověk, jež krom kritiky navrhl i jak to vylepšit.

Problém ovšem je, že udělat opravdu rozumné vyhledávání je otázkou opravdu na knihu. Tyto dva články rozebírají takřka jen teorii, ale implementace by byla opravdovým oříškem.

Podle mě by bylo fajn, kdyby se tu někde objevila funkční knižnice tokenizátoru, která by si rozumně poradila i s češtinou. Mě by na to stačil alespoň seznam českých koncovek, kdyby ho někdo měl byl bych mu opravdu vděčný, už mám i seznam synonym a podobných věcí.

To na co ale narážím nejvíce je omezený počet zdrojů na vytvoření vyhledávání. Ono totiž není dost dobře možné naprogramovat dobré vyhledávání za rozumný čas. Podle mě je škoda, že se na to nemyslí už v databázích, protože tam kdyby existoval rozumný fulltext by to bylo nejrychlejší a nejlepší. Jistou možností nad kterou v poslední době uvažuji je napsání nějakého tokenizátoru přímo do databáze a zbytek řešit přes triggery a SQL kód. Nevýhodou je, že MySQL je dost slabá na takové použití a pochybuji, že někdo bude menší projekty programovat pro něco jiného.

Fulltext s převáděním českých slov na základní tvar podle slovníku a podporou synonym poskytuje například modul tsearch2 do PostgreSQL - viz tady na Rootu http://www.root.cz/clanky/fulltextovani-v-postgresql-modul-tsearch2/
S tou implementací bych to tak složitě neviděl. Když jsem kód ukázkový kód pro článek testoval, vytvořil jsem indexátor dopsáním méně než 10 řádků v PHP. Konstrukce dotazů pro nejjednodušší případy všechna slova v dotazu OR nebo všechna AND nejspíš nezabere o moc větší počet.