Názory k článku PHP pro experty: Vyhledávání (2) - praktická realizace

nuz, fakt nechapem suvis nadpisu clanku a obsahu.
podla mna si to skor zasluzi nadpis "PHP pre zaciatocnikov" :).

- kdo píše jakoukoliv obezličku jen proto, že jeho hosting mu "cosi" neumožňuje, to není expert
- kdo není na homepage projektu http://smartbee.sourceforge.net/ schopen napsat k čemu to je, to není expert
- kdo se snaží navázat svoji funkčnost na handler 404, to není expert
- kdo používá smarty, to není expert :)

Muzu se zeptat co je spatneho se smarty? Jen abych se nevydal spatnym smerem... :)

Smarty jsou tak strasne, ze jsou hostovane na php.net. Hosi z php to jsou oproti Novotnemu, uplne lamy, pan Novotny je preci chytrejsi.

Doufam, ze pan Novotny, zkusena lama naprogramuje vlastni jazyk, aby dokazala ze lidi od php jsou spatni. I ja jsem spatny, ale marne hledam lepsi clanek na rootu a nejaky projekt pana Novotneho.

hosi z php.net jsou schopni vygenerovat mj. tento kod - http://bugs.php.net/bug.php?id=31261

Nie kazdy z PHP.NET je nadsenec Smarty. Nevyhody Smarty som skopiroval z jednej mojej sukromnej spravy. Proti Smarty nic nemam, v duchu hesla "nech si kazdy pouziva co chce a co mu najviac vyhovuje", mne kazdopadne nevyhovuje :-)

Ak chce niekto viac informacii k danej teme, moze ma pokojne kontaktovat.

Nepto

------

Just few notes about Smarty. I'm strictly against Smarty template engine usage, because its usage brings you these problems:

1. The first one is, that template designer has to learn new pseudo-programming language. I consider this as a very contra-productive, since:

a. template designers are often not capable to learn any programming language, nor some tough one;

b. if template designer will either learn Smarty template language, he or she is not able to use it anywhere else, since it is language created just for the Smarty; in this case is HTML::Template::Platon or Savant template system much better, because it adds logic into templates in the PHP programming language; so this knowledge may be handy in several other cases.

2. There is a need for world-writeable directories. These directories are often difficult to create (via FTP in example) and difficult to maintain for average user. I requested/suggested once, that instead of world-writeable directories, database backend can be used. Compiled script will be fetched from DB and evaluated. Monte Ohrt did not like this idea. I do not know why, since other elements in Smarty page building process can be stored in the database (fe. cached templates). His quotes follow:

"I suppose it is _possible_, but it would be highly inefficient. You would have to eval' everything, and you couldn't take advantage of any acceleration."

"I'm not saying you couldn't do it, but Smarty does not support it. You're the first to even suggest it."

So the conclusion: Smarty is a nice piece of PHP software and his authors can be considered as a real PHP hackers, but it absolutely unusable for me.

Tak s těmito tvrzeními dost nesouhlasým.

1) Šablony je možné ukládat do databáze pomocí plug-inů. Standardně to možné není a je to výhoda, protože databáze opravdu není vhodná k ukládání souborů, které mají 100kB. Navíc z použití databáze žádné praktické výhody neplynou. Ano nemusí se nastavovat práva, ale to každý hosting podporuje, teda alespoň všechny hostingy co znám.

2) Ano designéři se musí učit nový jazyk, ale ten je relativně jednoduchý a navíc je dokumentován zvlášť.

Zvažuji, že zde napíšu článek o Smarty a o rapidním vývoji aplikací. To co lze ve Smarty, to je takový druhý div světa, když se to člověk naučí používat. Neznám rychlejší způsob vývoje aplikací, viděl jsem dost frameworků, ale Smarty je co do rychlosti vývoje jednička.

Typickým případem je projekt www.bblog.com, který využívá plně potenciál Smarty. Výhoda je v tom, že jednotlivé funkce jsou volány teprve z šablon. To znamená, že když se klient rozhodne web přestavět 5x, neztratí se výkon, protože se volají jen ty funkce, které jsou v šablonách.

Smarty vyžaduje odlišnou logiku tvorby aplikací. Aplikace se netvoří z logické stránky, ale z prezentační části. V tom je rozdíl - nejdřív tvořím design a pak implementuji funkce, narozdíl od klasické logiky kdy tvořím logiku na kterou dávám design.

Otázkou je, zda-li tento přístup každému vyhovuje

Je to určitě dobrý text. Problém s indexováním textu je tady vysvětlen dostatečně jasně. Pochopitelně slouží pouze jako odrazový můstek a tak to také beru.

Hmm, asi jsem se díval špatně, ale kde je tam nějak vysvětlena problematika indexování textu? Příjde mi to jako soubor INSTALL od nějaké knihovny v PHP, která může být docela šikovná, ale jak funguje, to se v článku zrovna neřeší.

jj nemam rad manualy kde sa povie ... tu mas moju knihovnu, nestaraj sa ako to funguje tu mas manual ako ju vyuzivat - fakt ma to znechutilo.

A co si precist prvni dil, kde je popsana teorie? :)

Teorie, která má s implementací pramálo společného (nebo má, pak ovšem implementace stojí za starou belu). Co si takhle přičíst diskusi pod prvním dílem?

jj ale radeji si nectete nic o bezpecnosti od pana konicka. tenhle kacirsky vyrok je pro usmani :)

Pro ošetření vstupu před nepovolenými znaky se velmi často používají regulární výrazy. Jejich výhoda tkví v naprosté univerzálnosti použití pro ošetření libovolného vstupu.

Pripájam sa ku komentáru od Radka. Problém indexovania textu tu vôbec vysvetlený nie je. Skutočne len ako nainštaliť knižnicu, nejaká kratučká ukážka kódu a to je asi všetko.

Ďalej sú tu v texťáku ukázane nejaké dve tabuľky, ale vôbec nie sú vysvetlené na čo presne slúžia a ako fungujú a ako funguje to vyhľadávanie (v minulom článku toto všetko bolo napr.). Keďže sa článok nazýva "PHP pre expertov", tak by som to čakal. Experti práveže chcú vedieť ako a prečo to funguje vo vnútri. Nainštalovať si to dokážu aj sami, prípadne s pomocou nejakého README. V podstate som sa z článku dozvedel ako nainštalovať knižnicu ale už ani jej použitie som nejak moc nepochopil (nie to ešte jej vnútorné správanie sa).

Ešte by som rád podotkol, že MySQL podporuje transakcie (samozrejme, musia byť vytvorené InnoDB tabuľky) aj vo verzii 3. Konkrétne to mám odskúšané na MySQL 3.23.49.

A ďalej, fakt som si nie istý, či použitie transakcií urýchli vkladanie dát do DB. Osobne si myslím, že ani nie, ale nemám to nijak overené ani odskúšané, proste je to iba môj názor. Tým smaozrejme nezavrhujem transakcie, ktoré sú super vec. A aj v tomto prípade by mi šlo hlavne o integritu dát - bez ich použitia ak by náhodou nastal problém pri indexovaní nejakého článku, tak by som skončil tak, že by bola zaindexovaná iba jeho časť a nie celý. Nejaký zvýšený výkon vďaka transakcii určite nepocítim.

Ešte opäť ja. :)

Kukal som aj tu stránku, ktorej súčasťou má byť tá knižnica (http://smartbee.sourceforge.net/). A tiež to tam vyzerá, ako keby bolo na projekt uvalené informačné embargo. ;) Dozvedel som sa pár vlastností, ktoré SmartBee má, videl pár obrázkov (z ktorých som moc nepochopil) a ešte si prečítal hlavné ciele projektu a poďakovania. Ale stále neviem, na čo to má slúžiť! Keďže vo vlastnostiach bolo písane o automatickej zmene veľkosti obrázkov, tak prvé čo ma napadlo je, že je to nejaká fotogaléria. Ale myslím, že sa mýlim.

Pěkný pokus o "pokročilé" fulltextové vyhledávání. Články nemají teoretický základ, jsou útržkovitě a nepřesně podány a napsány dosti jednoduše.

Autor uvádí: "Využití transakcí má tedy vliv pouze na vkládání dat do databáze, nikoliv již na samotné vyhledávání."

To není u MySQL docela pravda, MyISAM tabulky jsou jasně nejrychlejší variantou, používat transakce jen kvůli rychlosti indexování je holý nesmysl, data tam lze rychle nahrnout i jinak.

Musel jsem se zasmát u poznámky o "komerčních produktech". Soudě podle znalostí autora o OOP a typické chybě s užitím dědičnosti v případě, kde by se naprosto jednoznačně měla použít skladba, to asi produkty moc kvalitní nebudou.

Divím se, že článek vůbec na rootu vyšel. Nestačí, když šéfredaktor umí dobře česky, musí mít široký přehled. Být šéfredaktorem roota, takový článek by putoval rychlostí kulového blesku zpět autorovi.

Ja se naopéak divim, ze zde nevysel clanek od nikoho jineho kdo tu remca. Uz se tesim na vase vytvory panove, taky si zakritizuji.

Nikdo z vas zde nemel konstruktivni pripominku, vsechno jen nepodlozena kritika bez slova tohle lze resit lepe a takhle. Byt ja sefradaktor, nekonstruktivni komentare jdou do kose stejne jako na hulan.info/blog

jj pamatuji si moc dobre jak jste tady naposledy plkal blbosti o regularnich vyrazech pane ing a mgr.

No někdo mi naposled zas do mailu hodil teoretický román, který neměl s praxí nic společného, že ;-)

Já jsem v klidu, nejsem na diskuzních fórech proslulý jako 100% rejpal

no nevim. teoreticky byla vase teze blbost. regularni gramatiky jsou ty nejednodussi, tak me udivilo prohlaseni, ze jsou univerzalni a hodi se na osetreni vsech vstupu. porad jsem cekal, ze mi poslete nejaky priklad na osetreni treba vsech zadanych palindromu. misto toho, aby jste uznal svou chybu, tak jste si bezduse stal za svym nesmyslnym tvrzenim. ocenuji lidi, kteri dokazi uznat svou chybu. vy vsak mezi ne zrejmne nepatrite.

poucte me nekdo co je mysleno zde "skladbou" naproti dedicnosti v OOP? (cit.:"Musel jsem se zasmát u poznámky o "komerčních produktech". Soude podle znalostí autora o OOP a typické chyby s užitím dedičnosti v prípadu, kde by se naprosto jednoznačne mela použít skladba, to asi produkty moc kvalitní nebudou. ")

Pokial to nie je vtip, tak tu je seriozna odpoved:

Google query: composition vs inheritance

http://tinyurl.com/5v26d

V zasade sa jedno o to, ci nova trieda vychadza z povodnej (dedicnost/inheritance), alebo trieda obsahuje inu triedu ci triedy (skladba/composition).

Existuje mnoho pripadov, kde je pomerne jednoduche rozhodnut, ktoru z uvedenych metod pouzit (na internete najdete mnoho ucebnicovych prikladov). Nejde to vsak vo vseobecnosti, tj. existuju modelove situacie, pri ktorych arguementy hovoria aj za dedicnost, aj za skladbu. Moj osbny nazor je, ze spravne rozhodnutie predurcuju najma prakticke skusenosti z oblasti vyvoja softveru.

Hmm. Tak to jsem zase chytřejší (bez ironie). A nebylo by něco česky/slovensky? Ta anglina mi nic moc.

Co když chci dědit více tříd? V PHP to podle všeho nejde. Tak musím použít skladbu, páč jinak ji tam nedostanu. Nebo to de jinak?

Nie celom rozumiem otazke. Skladbou je mozne vlozit lubovolne vela objektov. Podobne dedicnostou je mozne dedit z konecne vela tried, samozrejme sposobom, ze druha vychadza z prvej, tretia z druhej, n-ta z n-1-vej, atd.

Dedit z viacerych tried naraz v PHP nejde, ale da sa to obist vhodnou kombinaciou skladby a dedicnosti, tj. vytvorime si meta-triedu, ktora skladbou obsahuje dve triedy a z tejto meta-triedy nasledne dedime.

Tento navrh je vsak spletity a zmatocny, navyse sa ciastocne mina povodnemu zameru. Osobne by som ho nepouzival. Rovnako tak neprospieva citatelnosti kodu.

v cem jsou transakce rychlejsi nez:

INSERT INTO tabulka VALUES
(1, "ahoj"),
(2, "cau"),
(3, "nazdar");

?

pokud by se tim chtel autor clanku inspirovat, je tento kus kodu vydan pod BSD licenci ;-)

Leda tak prd a ne BSD licence...

Zas lidi z Microsoftu, dokonce i 3 radky kodu musi mit licenci, kdyz uz to nejde prodat :-o

ne, pan neni z m$, pan chce poskytnout tento jednoduchy kod autorovi knihovny, ktery zrejme neumi vice radek insertovat najednou. a aby autor nemel problemy s jeho zaclenenim, rovnou sopecifikuji licenci. mas neco proti BSD licenci?

a nejsou to tri radky, je to tak maximalne jeden radek, jenom tak na okraj :-)

o vice radkach jsem opravdu nevedel, nicmene i tak je to s transakcemi rychlejsi, protoze se to dava do databaze postupne a php nevytvari dalsi retezec o velikosti treba 100k.

Nicmene tam kde neni podpora transakci je to dobre reseni, to uznavam.

Nemá každý MySQL s nestandardními syntaktickými ozdobičkami. Obecně lze jistě tvrdit, že mnoho insertů je lépe provádět v jedné transakci. Tím spíš, že transakční log je třeba na separátním disku.

v clanku se mluvi o transakcich v mysql.

btw, podle http://en.wikipedia.org/wiki/Insert_(SQL) to umi i DB2.

navic muzes udelat insert do jedny tabulky a pak INSERT ... SELECT do ty hlavni ;-)

Jenom bych upresnil, hovori se o transakcich v MySQL, ale knihovna podporuje vice databazi pres vrstvu EzSQL. Priklad pri vymene knihovny EzSQL lze pouzit take na SQLite, Oracle ci PostgreSQL.

Nicmene alespon diky za vysvetleni, proc jsem tenhle vice SELECT neznal, naucil jsem se jen SQL a zvlastnosti MySQL tak do detailu prozkoumane nemam, i kdyz uznavam ze jsou mnohdy velmi uzitecne, treba syntaxe INSERT ... SET je nepostradatelna.

ad pomalost (a predpokladam i zravost pameti):
- Pristup k databazi funguje tak, ze se do pameti nacte cely result set, ktery se pak predava dale jako pole. U dotazu vracejicich par radku vam to mozna nevadi, ovsem co se kuprikladu stane, kdyz se pokusime zaindexovat uz existujici databazi? Metoda 'search::add_results' nacte celou tabulku ... Soubor 'ez_sql.php' je vubec kapitola sama o sobe.
- Kdyz se v nejakem clanku objevi stokrat slovo 'konicek', tak v tabulce 'search' bude sto zaznamu, u nichz se, az prijde od nejakeho uzivatele dotaz na 'konicka', secte celkove 'score', a to pak s prislusnym id dokumentu preklopite do tabulky 'search_tmp'. Proc? Ve skutecnosti by stacila pouze tabulka 'search_tmp' s daty, ktera nesmyslne generujete stale dokola. Tabulka 'search' (alespon pri algoritmu, ktery pouzivate) je zcela zbytecna.
- To, jak cvicite se 'search_tmp', abyste obhospodaroval "nakesovana" slova, akorat dale zpomaluje vyhledavani. Vubec mam pocit, ze se na databazi snazite posilat co nejvice (pokud mozno co nejdelsich) dotazu.
- Mel byste vyzkouset index na 'search.value' a 'search_tmp.string'. Nicmene vzhledem k neprilis podarenemu navrhu bych i uveril, ze to nepomuze, nebot v 'search_tmp' odmazavate starsi vysledky (takze bude mala) a v 'search' se zbytecne opakuji data (takze selektivita beztak nebude ohromujici).

ad race-conditions:
Vetsinou se to toci kolem tabulky 'search_tmp', ktera funguje jako jakasi kes. Nikdo se ale uz neobtezoval zajistit jak konzistenci se 'search', tak dusledne oddeleni uzivatelu.
Napr: 'search::_check_tmp' neupdatuje sloupec time. Takze az se za vhodnych podminek sejdou dva uzivatele, muze jeden promazavat tabulku 'search_tmp' pod rukama toho druheho, ktery se asi nebude stacit divit, co ze to dostava za vysledky.

ad tokenizator:
- Ten co tam mate, se hodi pro indexovani nezaludneho plain textu. Co se stane, kdyz kupr. nebudou za interpunkci mezery? Co se stane, kdyz budete indexovat texty s html formatovanim typu <code>strlen</code>?
- Pouzivate jeden pro indexovani dat, a jiny pro parsovani uzivatelskych dotazu. Z cehoz vyplyva, ze pri hledani vhodnych retezcu, ktere v dokumentech urcite jsou, nemusite najit vubec nic.

A je toho daleko vice. Vazne by me zajimaly podrobnosti o tech komercnich pouzitich. Navrh projektu a ani jeho implementace na me rozhodne nepusobi "expertnim" dojmem. Na rootu IMHO nema co delat, ale to je problem spise redakce, ze.

1) Nacteni celeho resultsetu jako pole nevadi a vykon to nekazi, i kdyz na to dost programatoru narazi. Pokud vim, je tam LIMIT 10, a pak se jedna o nacteni 10ti zaznamu. V pripade, ze se pouziva LIMIT tento pristup neovlivnuje vykon.

2) Tabulka Search_Tmp je urcena pro vyhledavani vice slov, jinak by tam nemusela byt, s tim souhlasim.

3) Tokenizator se da upravit. To je projekt od projektu, myslim ze to dost lidi zvladne.

4) U tabulky search_tmp oddeleni uzivatelu neni treba. Take jsem uvazoval jestli se nemuze stat, ze by to jeden uzivatel mazal druhemu. Otazka je, jestli situace kdy dojde k tomuto selhani je pravdepodobna - v tomto pripade by musel dotaz na nejaky vyraz dojit stejne tak do 10us. A osetrovat tohle dalsim kodem mi prijde relativne zbytecne. Navic nejde o 1 radek, tech moznosti kolizi je tam dost, ale nejedna se preci o bankovni aplikaci, kde by jeden pripad z milionu neco znamenal.

> nejedna se preci o bankovni aplikaci

jiste, proto nebudeme pouzivat lockovani... ach jo...

1) Ve verzi, kterou jsem si ja stahl (1.0.0), zadny limit neni. Limit by vykon samozrejme ovlivnil, protoze byste na db posilal mraky zbytecnejch dotazu. Programatori na tahani db dat do pameti narazeji opravnene, protoze jde o naprosto zbytecne plytvani pameti a procesorovym casem.

2) Spatne jste to pochopil, zbytecna je tabulka 'search'. A s vyhledavanim vice slov to nema nic spolecneho.

3) No pokud si maji uzivatele napsat i tokenizator, tak o cem byly ty dva clanky? Ale mate pravdu, stejne do nej bude treba rejpat, schvalne si poslete dotaz typu 'jedna -- hodne mezer -- dva'.

4) Ono je to mnohem variabilnejsi, to s tema dvema byl jen drobny prikladek. Data ze 'search_tmp' si muze promazavat uzivatel i sam sobe a nikoho dalsiho na to nepotrebuje. Nebo kdyz vymazete dokument z indexu, v 'search_tmp' az pul hodiny zustanou viset stara data (dokonce metoda 'article_query' pravdepodobne specialne kvuli tomu pouziva left join, abychom o NULL vysledky neprisli). Atd ...
Ano stary dobry pristup k chybam - tohle se preci nemuze stat, a kdyz tak, jednou za tisic let. Tech 10us si cucate z prstu (maximalne o nich lze uvazovat jako o dolnim odhadu), zalezi to na rychlosti a vytizenosti stroje + na konkretni delce dotazu od uzivatele. Komicky na tom je, ze se jedna o umele vytvoreny problem, protoze tabulku 'search_tmp' staci vygenerovat jen jednou, a nic z ni mazat nemusite. Ale to uz se opakuji.

A to jsem se minule zapomel alespon letmo zminit o zachytavani chyb, ktere v podstate neexistuje. Takze kdyz neco nevyjde, uzivatel tridy 'article_search' to nema sanci zjistit (i kdyz je pravda, ze tohle se z vetsi casti tyka uz 'db_mysql').

Rad by som sa vyjadril k prvemu bodu. Nie som celkom "in", pretoze kod som nestudoval, ale ak som pochopil diskusiu, v zasade sa jedna o riesenie problemu o viacnasobnej pouzitelnosti vysledkov z jedneho dotazu (query).

Riesenie je mozne viacerymi sposobmi, pricom medzi najhorsie sa rata ulozenie celeho vysledku (result) do pola. Pokial je nasim cielom vykon a jedna sa o pomerne obsiahly vysledok (result), je vhodne pouzit metodu pretacania vysledku (result rewind). Na toto dobre posluzi funkcia mysql_data_seek().

Zataz tak ostane na databazovom serveri, ktory si uschovava smerniky na zaznamy konkretneho vysledku (result). Tie, ak potrebujeme napriklad vypisat, jednoducho tahame (mysql_fetch_row()) a popritom spracovavame (vypisujeme). Ak ich potrebujeme spracovat opatovne, tak pretocime vysledok (result) a spracovanie opakujeme. Vyhodou je, ze nemusime plytvat pamatou PHP a nemusime tiez posielat sietou dalsi dotaz (query). V tomto pripade tak nejde ani o sietovu prevadzku (poslanie query vela trafficu nenarobi), ale o opatovne zatazenie DB servera (aj ked moderne DB servery uz maju query cache...).

Ked uz data spracovavat nepotrebujeme, result _uvolnime_ a dame tak DB serveru vydychnut.

Je skutocne pozoruhodne, ze vela PHP programatorov tento postup nepouziva, pritom sa s nim daju dosiahnut podstatne zlepsenia vo vykone.

Po precitani clanku(oboch) a diskusie som dospel k nazoru, ze ako som mohol doteraz zit. Urcite ci musim nieco podobne implementovat do stranky.
No po prezreti diskusie by som bol rad keby mi niekto poradil aj ine (asi kvalitnejsie) zdroje. Alebo nebodaj spristupnil svoju kniznicu funkcii. Ved teoreticky popis mam.
Vopred dakujem