*În ultima lună şi ceva m-am bazat pe '''Gregarius''', un agregator de feed-uri pentru web care rulează via Apache. Am dat peste el citind un ghid de instalare de pe blogul lui Paul Stamatiou şi mi-a plăcut destul de mult. Un „web based feed agregator" e bun la casa omului pentru că poţi citit '''RSS'''-urile de la orice calculator. Faptul că le afişa în clar, fară să introduc un username şi o parolă mă bucura şi mai mult pentru că se diminuau şansele ca cineva să îmi afle parola. De asemenea, nici interfaţa ajaxiană nu e de lepădat.<br> Ei bine, zilele astea am început să folosesc ceva mai intens bookmarklet-ul care îmi adăuga automat feed-ul paginii curente în lista de feed-uri. Relativ rapid, lista de '''RSS'''-uri a crescut de la vreo 4-5 la vreo 30, fiecare cu vreo 20-30 de item-uri necitite. Surpriză mare, dar aplicaţia dădea semne de oboseală, la nici 700 de item-uri: erau numai primele zece ştiri afişate dintre care vreo 3-4 ieşeau din dreptunghiul pe care le încadrau. <br> Iniţial, am zis în sinea mea că de vină sunt câteva itemuri aiurea şi trebuie să le marchez ca citite şi să nu le mai afişeze.<br> Însă aplicaţia afişa cam toate articolele, dar tot era ceva în neregulă cu display-ul. În plus, când încercam să export OPML-ul ca să îl import în News Alloy, nu îmi genera nici un OPML. Ceva nu mergea, aşa că am deschis phpMyAdmin-ul şi am tras cu ochiul la structura tabelei „item", acolo unde sunt depozitate elementele download-ate de pe net.<br> Înainte să trec mai departe, trebuie să menţionez că am lucrat cu extrem de puţine baze de date. Mai am mult până să mă numesc un iniţiat în acest domeniu. Cu atât mai mult, nişte greşeli care mi se pare mie evidente ar trebui să pară oricui, mai ales dacă ai sub centură o aplicaţie web.<br> Totuşi, sunt câteva chestii de bază pe care le-am învăţat fie din proprie experienţă, fie citind diverse articole pe net. De exemplu, normalizarea unei baze de date (pe româneşte, optimizarea unei baze de date):<br> În primul rând, o bază de date care este se adaugă şi se scot elemente frecvent, precum cea folosită de '''Gregarius''', trebuie să conţină cât mai puţină informaţie redundantă. Gradul de „optimizare" este măsurat în forme normale, în funcţie de complexitatea bazei de date. Sunt şase forme normale, dar majoritatea aplicaţiilor web nu depăşesc a patra formă normală, iar pentru '''Gregarius''' ar fi absolut suficient o bază de date care să satisfacă forma trei normală.<br> Mult mai clar ar fi un scurt exemplu. Să considerăm o bază de date care va ţine persoanele participante la o serie de prezentări (ceva în genul [http://reg.studentclub.ro/ <u>reg.studentclub.ro]</u>). Sigur o să fie cel puţin o tabelă care o să conţină numele, prenumele, o adresă de email şi prezentările la care va participa. <br>  <br> Tabela din stânga nu este normalizată şi are cel puţin o problemă extrem de serioasă: ce se întâmplă dacă există o persoană care se înscrie la a patra prezentare\’ Dar la a cincea\’ Putem să modificăm extrem de rapid acest aspect specificând o singură prezentare per intrare şi având mai multe intrări de genul:<br> "Maxim" "Andrei" "spam@andreimaxim.ro" "Prima prezentare" "Maxim" "Andrei" "spam@andreimaxim.ro" "A doua prezentare" "Maxim" "Andrei" "spam@andreimaxim.ro" "A treia prezentare" "Maxim" "Andrei" "spam@andreimaxim.ro" "A patra prezentare"<br> şi aşa mai departe. In acest moment, avem o bază de date forma unu. Însă multă informaţie e redundantă (ceea ce ar fi o treabă bună dacă am face analize pe această bază de date, deoarece ar reduce timpul de lucru, dar nu asta ne interesează acum). Aşa că vom trece la forma doi normală, unde vorbim de un primary key, adică unul sau mai multe elemente care să identifice unic un rând dintr-o tabelă.<br> Folosind exemplul de mai sus, un element care ar putea să identifice unic fiecare rând ar fi adresa de email, care va trebui oricum să fie unică. E recomandat să nu se folosească această metodă pentru că o cheie primară ideală ocupă puţină memorie, iar o adresă de email poate fi destul de lungă (de exemplu, andreimaxim@andreimaxim.ro are 26 de caractere, adica ocupă 26 de bytes în SQL Server). Dacă folosim o cheie primară „artificială", adică adăugăm un număr pentru fiecare linie introdusă, avem o cheie mult mai scurtă, de numai 4 bytes, putând acoperi mai bine de 2 miliarde de intrări.<br> În acest moment am reuşit să introducem un element în plus în tabela noastră. Dar în acest moment putem sparge baza de date în două, folosindu-ne de ParticipantiId: <br>  <br> Relaţia dintre cele două tabele a stabilit un Primary Key (PK) şi un Foreign Key (FK). A doilea tip de cheie arată că elementele din câmpul ParticipantiId din tabela ParticipantiLaPrezentari este cheie primară în tabela Participanti. Făcând această mutare am reuşit să trecem de la forma unu normală la forma doi normală. De asemenea, în acest moment se va repeta un număr pentru fiecare prezentare, nu un set întreg de nume, prenume şi adresă de email.<br> Pentru a treia formă normală, tabelele trebuie să fie ceva mai complexe. De exemplu, se stochează în baza de date şi numele prezentatorului. În cazul acesta, tabela a doua, ParticipatiLaPrezentari, va mai conţine încă o coloană. Faţă de primul caz, lucrurile sunt un pic mai dificile pentru că: <br> se poate defini o cheie primară din cuplul ParticipantId şi Prezentare, deci nu ar avea sens introducerea unei chei primare artificiale, ca în prima tabelă<br> deşi numele prezentatorului se repetă, diferenţa de spaţiu ocupat nu va fi aşa de mare<br> A treia formă normală precizează că toate coloanele din tabelă să aibă legătură numai cu cheia primară şi cu nimic altceva. În cazul acesta, numele prezentatorului nu ar avea legătură decât cu numele prezentării, nu şi cu participanţii. Mişcarea logică ar fi să se creeze o tabelă pentru fiecare prezentare, cu coloanele PrezentareId, Nume şi Prezentator, iar în tabela ParticipantiLaPrezentari să fie trecut ParticipantId şi PrezentareId. În acest moment am avea o bază de date extrem de simplă adusă la forma trei normală. Evident, cu cât datele sunt mai complexe, cu atât e mai dificil aducerea la o formă trei.<br> După o paranteză foarte lungă, revin la '''Gregarius'''. După cum spuneam, am deschis phpMyAdmin ca să mă uit dacă sunt probleme în baza de date.<br> Primul lucru care m-a surprins a fost organizarea: feed-urile „principale" sunt puse într-o tabelă item, iar feed-urile celor de la '''Gregarius''', care ajung pe dashboard, sunt trecute într-o altă tabelă, numită dashboard (ingenios, nu\’). M-am uitat mai atent şi la celelalte tabele, dar acolo s-au folosit tipuri complexe, cred, pentru o anumită coloană.<br> După cum ziceam, toate articolele erau puse într-o tabelă intitulată item, care are următoarea structură: <br>  <br> Dacă id-ul şi cid-ul (channelId) sunt destul de clare, deşi nu văd de ce s-ar folosi bigint, numerele din paranteză fiind doar legate de afişare, lucrurile devin dubioase când intrăm în md5sum şi GUID. De ce s-ar genera un MD5 pentru ''fiecare articol în parte''\’ Iar la GUID lucrurile sunt şi mai încurcate: pentru majoritatea blogurilor, GUID-ul este identic cu URL-ul (hopa!), pentru câteva seamană cu un GUID autentic, iar pentru altele, gen [http://coolthingoftheday.blogspot.com/ <u>Cool Thing of the Day]</u>, e un şir de caractere destul de interesant gen „tag:blogger.com,1999:blog-5655811.post-11468591940…". Altele nu au deloc GUID (blogul celor de la 37signals). Evident, title ţine titlul articolului, iar URL adrese acestuia. Un alt semn de exclamare a apărut la unread, care ar trebui să fie un simplu BOOL sau BIT, dar uitându-mă în manualul de MySQL observ că pentru versiunile pre 5.0.3 TINY(1), BIT şi BOOL sau BOOLEAN sunt identice.<br> În cazul lui '''Gregarius''', lucrurile pot fi cât de cât OK, deşi a reuşit să ocupe cam 3 MB după câteva zile de funcţionare ceva mai intensă. Chiar dacă e versiunea 0.5.4 şi schema bazei diferă de versiunea 0.5.2, ar trebui ca până acum să se fi ajuns la o formă cât de cât decentă. Însă există destul de multe probleme cu aplicaţiile web care se folosesc baze de date, tocmai din cauza unei organizări cel puţin defectuase ale datelor.<br> Oare toate aplicaţiile noi, promovate cu atâta ardoare, pun mai mult accent pe interfaţă sau sunt ''numai'' interfaţă grafică\’<br> '''Gregarius''' se pare că întăreşte acest punct de vedere.<br>

*În ultima lună şi ceva m-am bazat pe '''Gregarius''', un agregator de feed-uri pentru web care rulează via Apache. Am dat peste el citind un ghid de instalare de pe blogul lui Paul Stamatiou şi mi-a plăcut destul de mult. Un „web based feed agregator" e bun la casa omului pentru că poţi citit '''RSS'''-urile de la orice calculator. Faptul că le afişa în clar, fară să introduc un username şi o parolă mă bucura şi mai mult pentru că se diminuau şansele ca cineva să îmi afle parola. De asemenea, nici interfaţa ajaxiană nu e de lepădat.<br> Ei bine, zilele astea am început să folosesc ceva mai intens bookmarklet-ul care îmi adăuga automat feed-ul paginii curente în lista de feed-uri. Relativ rapid, lista de '''RSS'''-uri a crescut de la vreo 4-5 la vreo 30, fiecare cu vreo 20-30 de item-uri necitite. Surpriză mare, dar aplicaţia dădea semne de oboseală, la nici 700 de item-uri: erau numai primele zece ştiri afişate dintre care vreo 3-4 ieşeau din dreptunghiul pe care le încadrau. <br> Iniţial, am zis în sinea mea că de vină sunt câteva itemuri aiurea şi trebuie să le marchez ca citite şi să nu le mai afişeze.<br> Însă aplicaţia afişa cam toate articolele, dar tot era ceva în neregulă cu display-ul. În plus, când încercam să export OPML-ul ca să îl import în News Alloy, nu îmi genera nici un OPML. Ceva nu mergea, aşa că am deschis phpMyAdmin-ul şi am tras cu ochiul la structura tabelei „item", acolo unde sunt depozitate elementele download-ate de pe net.<br> Înainte să trec mai departe, trebuie să menţionez că am lucrat cu extrem de puţine baze de date. Mai am mult până să mă numesc un iniţiat în acest domeniu. Cu atât mai mult, nişte greşeli care mi se pare mie evidente ar trebui să pară oricui, mai ales dacă ai sub centură o aplicaţie web.<br> Totuşi, sunt câteva chestii de bază pe care le-am învăţat fie din proprie experienţă, fie citind diverse articole pe net. De exemplu, normalizarea unei baze de date (pe româneşte, optimizarea unei baze de date):<br> În primul rând, o bază de date care este se adaugă şi se scot elemente frecvent, precum cea folosită de '''Gregarius''', trebuie să conţină cât mai puţină informaţie redundantă. Gradul de „optimizare" este măsurat în forme normale, în funcţie de complexitatea bazei de date. Sunt şase forme normale, dar majoritatea aplicaţiilor web nu depăşesc a patra formă normală, iar pentru '''Gregarius''' ar fi absolut suficient o bază de date care să satisfacă forma trei normală.<br> Mult mai clar ar fi un scurt exemplu. Să considerăm o bază de date care va ţine persoanele participante la o serie de prezentări (ceva în genul [http://reg.studentclub.ro/ <u>reg.studentclub.ro]</u>). Sigur o să fie cel puţin o tabelă care o să conţină numele, prenumele, o adresă de email şi prezentările la care va participa. <br>  <br> Tabela din stânga nu este normalizată şi are cel puţin o problemă extrem de serioasă: ce se întâmplă dacă există o persoană care se înscrie la a patra prezentare\’ Dar la a cincea\’ Putem să modificăm extrem de rapid acest aspect specificând o singură prezentare per intrare şi având mai multe intrări de genul:<br> "Maxim" "Andrei" "spam@andreimaxim.ro" "Prima prezentare" "Maxim" "Andrei" "spam@andreimaxim.ro" "A doua prezentare" "Maxim" "Andrei" "spam@andreimaxim.ro" "A treia prezentare" "Maxim" "Andrei" "spam@andreimaxim.ro" "A patra prezentare"<br> şi aşa mai departe. In acest moment, avem o bază de date forma unu. Însă multă informaţie e redundantă (ceea ce ar fi o treabă bună dacă am face analize pe această bază de date, deoarece ar reduce timpul de lucru, dar nu asta ne interesează acum). Aşa că vom trece la forma doi normală, unde vorbim de un primary key, adică unul sau mai multe elemente care să identifice unic un rând dintr-o tabelă.<br> Folosind exemplul de mai sus, un element care ar putea să identifice unic fiecare rând ar fi adresa de email, care va trebui oricum să fie unică. E recomandat să nu se folosească această metodă pentru că o cheie primară ideală ocupă puţină memorie, iar o adresă de email poate fi destul de lungă (de exemplu, andreimaxim@andreimaxim.ro are 26 de caractere, adica ocupă 26 de bytes în SQL Server). Dacă folosim o cheie primară „artificială", adică adăugăm un număr pentru fiecare linie introdusă, avem o cheie mult mai scurtă, de numai 4 bytes, putând acoperi mai bine de 2 miliarde de intrări.<br> În acest moment am reuşit să introducem un element în plus în tabela noastră. Dar în acest moment putem sparge baza de date în două, folosindu-ne de ParticipantiId: <br>  <br> Relaţia dintre cele două tabele a stabilit un Primary Key (PK) şi un Foreign Key (FK). A doilea tip de cheie arată că elementele din câmpul ParticipantiId din tabela ParticipantiLaPrezentari este cheie primară în tabela Participanti. Făcând această mutare am reuşit să trecem de la forma unu normală la forma doi normală. De asemenea, în acest moment se va repeta un număr pentru fiecare prezentare, nu un set întreg de nume, prenume şi adresă de email.<br> Pentru a treia formă normală, tabelele trebuie să fie ceva mai complexe. De exemplu, se stochează în baza de date şi numele prezentatorului. În cazul acesta, tabela a doua, ParticipatiLaPrezentari, va mai conţine încă o coloană. Faţă de primul caz, lucrurile sunt un pic mai dificile pentru că: <br> se poate defini o cheie primară din cuplul ParticipantId şi Prezentare, deci nu ar avea sens introducerea unei chei primare artificiale, ca în prima tabelă<br> deşi numele prezentatorului se repetă, diferenţa de spaţiu ocupat nu va fi aşa de mare<br> A treia formă normală precizează că toate coloanele din tabelă să aibă legătură numai cu cheia primară şi cu nimic altceva. În cazul acesta, numele prezentatorului nu ar avea legătură decât cu numele prezentării, nu şi cu participanţii. Mişcarea logică ar fi să se creeze o tabelă pentru fiecare prezentare, cu coloanele PrezentareId, Nume şi Prezentator, iar în tabela ParticipantiLaPrezentari să fie trecut ParticipantId şi PrezentareId. În acest moment am avea o bază de date extrem de simplă adusă la forma trei normală. Evident, cu cât datele sunt mai complexe, cu atât e mai dificil aducerea la o formă trei.<br> După o paranteză foarte lungă, revin la '''Gregarius'''. După cum spuneam, am deschis phpMyAdmin ca să mă uit dacă sunt probleme în baza de date.<br> Primul lucru care m-a surprins a fost organizarea: feed-urile „principale" sunt puse într-o tabelă item, iar feed-urile celor de la '''Gregarius''', care ajung pe dashboard, sunt trecute într-o altă tabelă, numită dashboard (ingenios, nu\’). M-am uitat mai atent şi la celelalte tabele, dar acolo s-au folosit tipuri complexe, cred, pentru o anumită coloană.<br> După cum ziceam, toate articolele erau puse într-o tabelă intitulată item, care are următoarea structură: <br>  <br> Dacă id-ul şi cid-ul (channelId) sunt destul de clare, deşi nu văd de ce s-ar folosi bigint, numerele din paranteză fiind doar legate de afişare, lucrurile devin dubioase când intrăm în md5sum şi GUID. De ce s-ar genera un MD5 pentru ''fiecare articol în parte''\’ Iar la GUID lucrurile sunt şi mai încurcate: pentru majoritatea blogurilor, GUID-ul este identic cu URL-ul (hopa!), pentru câteva seamană cu un GUID autentic, iar pentru altele, gen [http://coolthingoftheday.blogspot.com/ <u>Cool Thing of the Day]</u>, e un şir de caractere destul de interesant gen „tag:blogger.com,1999:blog-5655811.post-11468591940…". Altele nu au deloc GUID (blogul celor de la 37signals). Evident, title ţine titlul articolului, iar URL adrese acestuia. Un alt semn de exclamare a apărut la unread, care ar trebui să fie un simplu BOOL sau BIT, dar uitându-mă în manualul de MySQL observ că pentru versiunile pre 5.0.3 TINY(1), BIT şi BOOL sau BOOLEAN sunt identice.<br> În cazul lui '''Gregarius''', lucrurile pot fi cât de cât OK, deşi a reuşit să ocupe cam 3 MB după câteva zile de funcţionare ceva mai intensă. Chiar dacă e versiunea 0.5.4 şi schema bazei diferă de versiunea 0.5.2, ar trebui ca până acum să se fi ajuns la o formă cât de cât decentă. Însă există destul de multe probleme cu aplicaţiile web care se folosesc baze de date, tocmai din cauza unei organizări cel puţin defectuase ale datelor.<br> Oare toate aplicaţiile noi, promovate cu atâta ardoare, pun mai mult accent pe interfaţă sau sunt ''numai'' interfaţă grafică\’<br> '''Gregarius''' se pare că întăreşte acest punct de vedere.<br>

[[Categorie:RSS]]

[[Categorie:RSS]]