Názory k článku Princip jednoduchého fulltextu s příklady v SQL a PHP (1)
-
Dalibor Šrámek (neregistrovaný)Pokud máte na mysli vyhledávání (a ne indexování), pak bych řekl, že algoritmus v této jednoduché podobě je značně efektivní. Implementace by ale šla zrychlit ještě hodně. Například nahrazením běžné relační databáze jako úložiště indexu vlastním řešením optimalizovaným pro dané datové struktury a cachováním velkého množství dat v RAM (včetně celého slovníku).
-
anonymníVyhledavani je dostatecne efektivni, ale totez si myslim i o "generovani invertovaneho souboru" a proto jsem se ptal na nej:)
Uvedený algoritmus rozhodně není optimalizován na výkon - cílem byla jeho snadná pochopitelnost.
Mozna jste myslel konkretni implementaci algoritmu... Nazornost implementace na ukor kvality kvuli snadnemu pochopeni a obecnosti beru jako samozrejmost. -
anonymníVyhledavani je dostatecne efektivni, ale totez si myslim i o "generovani invertovaneho souboru" a proto jsem se ptal na nej:)
Uvedený algoritmus rozhodně není optimalizován na výkon - cílem byla jeho snadná pochopitelnost.
Mozna jste myslel konkretni implementaci algoritmu... Nazornost implementace na ukor kvality kvuli snadnemu pochopeni a obecnosti beru jako samozrejmost. -
anonymnílen tak podla toho ako pozeram je spomalenie na select a ak neexistuje tak insert. Podla ma by bolo uzitocne a rychle pouzit hash, a asi aj dobre ho ukladat do db ako identifikator unikatnosti. potom uz len staci pouzit replace (alebo insert bez osetrenia chyby) co by mohlo byt rychlejsie ako cakanie na vysledok selectu.
-
anonymníPro začínající programátory v SQL a PHP mohl autor zmínit, že někdy je výhodné přesunou aplikační logiku do databáze a indexování (v tomhle konkrétním případě :-) ) implementovat pomocí triggerů a uložených procedur přímo v databázi. Jsou databáze, kde lze psát uložené procedury nejenom v SQL, ale i v C nebo v Javě.
-
Veď to je práve ten problém fulltextu v MySQL. Osobne sa mi nezdá mať dáta v DB dvakrát: raz s diakritikou a druhý raz bez nej aby si s tým poradil fulltext.
Zatiaľ som ešte nerobil web kde by som ocenil výhodu fulltextu. Radšej som siahol po vyhľadávaní v klúčových slovách, označeniach produktov, ... -
Dalibor Šrámek (neregistrovaný)V první řadě je článek o principu nikoliv o konkrétní realizaci. Příklady kódu vlastně jen popisují, jak to funguje. Mám za to, že pochopení, jak něco obecně funguje je užitečné třeba pro nastavení konkrétní aplikace/knihovny, která věc realizuje, a nakonec i pro člověka, který je jen uživatelem již hotové aplikace.
Nevím, proč redakce přiřadila textu nálepku MySQL. Obecnější nálepka SQL by byla lepší. A takhle jde udělat fulltext třeba i v SQLite... -
anonymníAhoj chlapi,
pod clanek k novymu rootu nejdou pridavat komentare, tak to soupnu sem, protoze se to sem taky hodi:
Mrzi mne, za ac mam monitor siroky 1600 pixelu, musim si posuvnikama rolovat zdrojovy kod v pidiokynku nejakych 470 pixelu... :-(
Tak to je tak vse, jinak clanek jako takovy je SUPER !! -
Dalibor Šrámek (neregistrovaný)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.) -
Akela (neregistrovaný)Otazka je ci je taketo riesenie pod PostgreSQL lepsie ako tsearch2. Osobne mam rozbehany tsearch na 1.5 Gb tabulke s 170000 zaznamamy. Priemerna velkost textu je 5 KB. Ked tabulka natiahnuta v pamati, tak sa daju dosiahnut casi pod 4 sec.
Zaujimalo by ma porovnanie tohoto riesenia vs tsearch2.
