Dost dobře nechápu, co je jako rychlější než "indexované vyhledávání v MySQL". Snad měl autor na mysli, že to bude díky indexu rychlé, pokud bude mít indexy na ID článku a slovu... S logaritmickou složitostí (o základu dva - většinou, zleží na typu indexu).
Řetězec standardizován? Co je to za pojem? Snad parsován ne? Rozhodně bych začal u kvalitního parseru. Ten je velmi důležitý a data může znehodnotit velice. Například internetové odkazy, emaily, zkratky. To všechno představuje problém. Pokračoval bych synonymy, stemmingem a stop slovy - některá slova nemá cenu indexovat, protože neposkytují informační hodnotu a jen zvětšují index (spokjy, částice, citoslovce atd).
Ty bonusy by neměly být tak velké, kvalitní fulltextové knihovny nedávají velké bonusy za kontext, ale spíše se zaměří na absolutní a relativní výskyty termu, délku dokumentu, entropii a podobně. Dokáží na základě statistických metod vyfiltrovat slova, které nejsou relevantní.
Tohle je opravdu _velmi_ jednoduchý fulltext s dvoustavovým výskytem, který jen se štěstím bude vykazovat dobré výsledky. Pokud něndo napříkad nadpisem vytvoří nějaký off-topic text v diskuzním příspěvku, velmi tak ovlivní chování algoritmu.
to ze se neco jmenuje ID jeste neznamena, ze je to PRIMARY klic. Toto nebylo explicitne v clanku uvedeno, i kdyz z kontextu to vyplyva. Predpokladam, ze to bude i auto_increment.
Ještě k té rychlosti: pokud bychom měli tabulku se strukturou navrženou v článku, tak slovo s častým výskytem (třeba ty neošetřená stop slova) by při použití v dotazu stejně způsobilo procházení (rozuměj operace s diskem) značné části tabulky index neindex. Ten bilión záznamů za milisekundy je opravdu velká nadsázka.
Místo score by možná bylo lepší ukládat prostě pořadí slova od začátku textu (text = nadpis + perex + tělo) a definovat nějakou funkci, která score spočítá. Umožní se tím i použití proximity operátorů (hledání frází) a algoritmus je nezávislý na uložení nebo strukturování článků.
BTW: sice je to PHP pro experty a ne SQL pro experty, ale opravdu by hledání více slov jedním dotazem vedlo k poklesu výkonu? Domnívám se, že v mnoha případech by to bylo naopak - minimálně pro spojení slov operátorem OR.
Ano, spojení slov OR by zvýšilo výkon prohledávání, nicméně uživatelé chtějí většinou AND. Google byl jeden z prvních vyhledávačů co přišel se standardním AND, v té době kdy altavista ještě používala OR.
Ohledně přiřazování scóre to záleží na parseru. Můžete si naprogramovat vlastní, který zohlední datum, pozici v textu, prostě cokoli. Mým cílem je představit základní implementaci, který si každý doupraví. Ostatně cílem článku je vyprovokovat programátory k vytvoření lepšího hledání a zaslání názorů a připomínek. Přeci jenom buďme upřímní, vyhledávání na mnoha webech je přinejmenším nedostačující.
S tím PHP pro experty máte pravdu, na SQL jsou ty jiní odborníci. Rád se přiučím pokud někdo zkomentuje výkony SQL v různých operací. Nejsem expert přes SQL, jediné co jsem potřeboval řešit byla opravdu velmi chabá možnost v SQL rozumně vyhledávat.
Některé výsledky hledání řazené podle data také podle toho vypadají. Zkuste si jen na Root.cz vyhledat slovo Slackware, o relevantnosti výsledku lze stěží mluvit, a takto je 80% webů. Root.cz je typickým příkladem, kdy komentář má stejnou váhu jako titulek článku a to se já snažím řešit.
SELECT Clanek_ID, COUNT(DISTINCT Slovo) AS wordcount, SUM(Score) AS relevance
FROM search
WHERE Slovo IN ('instalace', 'PHP')
GROUP BY Clanek_ID
HAVING wordcount = 2
ORDER BY relevance DESC;
Obecně je třeba brát v úvahu režii na parsování SQL dotazu a případně režii na vytváření temporary tabulky, ale tyhle věci záleží na použité databázi.
A teď mi řekněte, proč vymýšlet další super originální řešení web vyhledávače... Není jich snad dost?
Proč se radši nepřipojíte k nějakému z existujících projektů a nevylepšujete ho? Snad je nám všem jasné, že vyhledávačů jsou mraky a většina jich je velmi špatných i přesto, že na tom jejich vývojáři nechali spoustu a spoustu času.
Tak to si rad poslechnu jmena tech projektu, zadne takove jsem nenasel. Ano, jsou tu nejake v PHPcku, ale vetsinou se nejedna o knihovny, ale cele stroje, a to mi je jako asi vetsine PHP programatoru k nicemu.
BTW otazka jestli je jich dost je podle me irelevantni. To je jako rici je 1000 redakcnich systemu a stejne se vyvijeji dalsi a dalsi. Ono totiz kdyz clovek zacne ty RS prochazet, zjisti ze tenhle ma tuhle nevyhodu, tenhle onu, a tamten zas jinou.
Muj cil je nabidnout snadne, ciste reseni, ktere si kazdy doupravi.
