1. Z čeho autor vychází, když tvrdí, že tento způsob je rychlejší než "běžné indexované vyhledávání v MySQL", když hledání nad FULLTEXT indexem funguje principiálně podobně?
2. Když už je celý odstavec věnován popisu toho, jak je to úžasně rychlé, jak může zůstat nezmíněno, že nad sloupcem Slovo musí být vytvořen index, bez kterého to naopak bude velmi pomalé?
3. Proč není nad sloupci (Slovo, Clanek_ID) zřízen unikátní index a hodnoty v těchto sloupcích se mohou opakovat? Data se tak zbytečně nafukují a všechno se zpomaluje.
No nic, článek dobře zapadá do seriálu "PHP pro experty".
1. Hledani nad fulltextem funguje podobne, ale ne stejne. Predevsim vychazim z toho, ze standardni indexy nemaj cache a navic zaznamu v indexu neni tolik.
2. Ano, indexy by tam byt meli
3. Neznam zpusob jak zajistit, aby se data nenafukovala a nezpomalit vkladani dat do databaze. Nicmene muzete udelat SUM na celou tabulku a nekde v CRONu to jednou za mesic komprimovat, coz je asi nejefektivnejsi cesta.
No, s fulltextem mysql jsem mel v minulosti obcas problemy.
Jednak slovo, ktere se vyskytuje vice nez v 50% stranek to ignoruje (coz je blby hlavne ze zacatku kdyz je v systemu malo dokumentu, nebo kdyz nekdo zada hledani ve stylu "Bezneslovo AND Vzacneslovo" - pokud se "bezneslovo" vyskytuje ve vice nez 50% dokumentu, nenajde se nic)
Taky to neindexuje veci kratsi nez asi 4 pismena (jde to sice zmenit, ale chce to prava roota, neboli vrtat se v konfiguraci mysql, coz na hostingu neni.)
Cili kdyz hledam treba slovo "vlk" tak mam smulu ...
A ma to celkem dost problemu s diakritikou.
Na mensi mnozstvi dokumentu a pri male navstevnosti stranek lze pouzit "select ... where like '%slovo%'", jenze to prochazi pri kazdem hledani vsechny dokumenty v databazi, coz je celkem hloupe .... vetsi navstevnost ci mnoho dokumentu tohle uz neutahne.
Takze pak je potreba mit nejaky vlastni system .... to co tam je v mysql je spis takovy nanastavitelny quick fix nez poradne vyhledavani
Ignorování moc častých slov lze vypnout buď ve zdrojáku (je to sice popsáno v dokumentaci, ale moc použitelné řešení to opravdu není) nebo použít BOOLEAN MODE, který je k dispozici od MySQL 4.0.
1. Já tedy nevím, jak přesně bude cache implementována, ale podle toho nástinu, který je uveden v článku, k žádnému výraznému zrychlení nepřispěje. Rozhodně ne takovému, které by se nedalo zařídit i elegantněji.
3. Jde o to, že proces ukládání do databáze je už tak dost pomalý (což je zmíněno i v článku) a navíc se dělá na úrovni PHP. Z toho plyne, že je možné ho navrhnout tak, aby data ukládal efektivně a nevedl k výraznému zpomalení tohoto procesu, který navíc není tak důležitý, jako rychlost vyhledávání.
1. Cache je implementována na úrovni slov, v určitých případech ke zrychlení dojde. Pokud třeba máte server o PDA, a každý hledá text PDA xxxxx, tak potom se bude PDA tahat z cache a vyhledávat se bude jen druhé slovo. Nicméně samotný proces vyhledávání je již tak rychlý, že cache je tam spíše jako temporary tabulka, která mimo jiné cachuje, ale hlavně se z ní tahaj přímo výsledky a nikoli jednotlivá slova.
3. Ano je možné navrhnout jej, aby se data ukládala efektivněji. Nicméně se zvýší zátěž databázového serveru a ne PHP serveru. Zatímco já ukládám slovo jedním SQL dotazem, ostatní řešení potřebují minimálně 2 SQL dotazy. Navíc jak říkám, výkonově je mé řešení lepší, protože nevzniká fragmentace a data jsou do databáze ukládány sekvenčně. Z mých zkušeností je lepší řešení než tady něco sečíst a pozměnit raději to všechno naházet na hromadu a pak jednou za čas přepočítat tabulku.
