Poate parea trist ca aruncam la gunoi aproape un an de efort, dar nu este cazul. Vom pastra tot continului site-ului, care valoreaza enorm (si asta tine de fapt infoarena.ro in viata). Si vom pastra lectiile infoarena2, care sunt mult mai valoroase decat codul php. Daca am fi alti omaeni care am rescrie codul probabil ca am face aceleasi prostii, si atunc ar mai bine sa ne tina de treaba la infoarean2.

Am facut o lista cu ce anume am gresit in infoarena2 si cum putem face mai bine (in infoarena3). Este posibil sa reparam multe dintre probleme fara o rescriere, dar nu toate. Multe dintre aceste greseli vizeaza arhitectura fundamentala a site-ului. Acestea nu pot fi reparate decat printr-un efort enorm, iar acel efort cumulat ar fi mai mare decat o rescriere de la 0.

Am facut o lista cu ce anume am gresit in infoarena2 si cum putem face mai bine (in infoarena3). Este posibil sa reparam multe dintre probleme fara o rescriere, dar nu toate. Multe dintre aceste greseli vizeaza arhitectura fundamentala a site-ului. Acestea nu pot fi reparate decat printr-un efort enorm, iar acel efort cumulat ar fi mai mare decat p rescriere de la 0.

h3. ia_parameter_values

Ar trebui sa avem pentru fiecare tip de problema sau runda un tabel de genul ia_classic_task, care contine o coloana task_id si apoi cate o coloana pentru fiecare parametru. Eu (Leonard) am incercat aceasta transformare dar nu am reusit (din cauza repercursiuni in restul site-ului) si am renuntat.

h3. Tabelul ia_score

h3. ia_score

Tabelul ia_score are coloanele: score_id, user_id, task_id, round_id si score. Primele 4 coloane sunt sunt nulabile, asa ca tabelul nu are PK. Ideea era sa tinem scoruri per runda cu task_id NULL si eventual statistici per task/round cu user_id NULL. Astfel puteam sa tinem toate scorurile in acelasi tabel. Din pacate am ajuns in situatia de a avea mai putine statistici decat in infoarena1. Asta cred ca este singurul punct in care infoarena1 depaseste infoarena2.

Tabelul ia_score are coloanele: score_id, user_id, task_id, round_id si score. Primele 4 coloane sunt sunt nulabile, asa ca tabelul nu are PK. Idea era sa tinem scoruri per runda cu task_id NULL si eventual statistici per task/round cu user_id NULL. Este un tabel oribil si mi-e rusine de ce am facut acolo.

Este un tabel oribil si mi-e rusine de ce am facut acolo. Este incet, urat si greu de facut query-uri.

Este prea greu sa faci query-uri in tabel si din pacate infoarena1 avea de fapt mai multe statistici decat infoarena2. Asta cred ca este singurul punct in care infoarena1 depaseste infoarena2.

Acest tabel ar trebui spart in mai multe tabele fara coloane nulabile. Idea fundamental gresita de aici a fost economisirea numarului de tabele din baza de date. Este ca si cum ai incerca sa folosesi cat mai putine functii facand copy-paste in main().

Acest tabel ar trebui spart in mai multe tabele fara coloane nulabile. Idea fundamental gresita de aici este economisirea numarului de tabele din baza de date, care este o prostie. Este ca si cum ai incerca sa folosesi mai putine functii facand copy-paste.

h3. Id-uri {VARCHAR(64)}

h3. Id-uri VARCHAR(64)

Id-urile pentru utilizatori sunt numere, dar restul sunt {VARCHAR(64)} cu niste validari facuta in cod prin regex-uri. Ar fi mai bine sa avem toate id-urile drept numere, spre exemplu task_id int si task_name string. task_name se poate obtine foarte usor din task_id adaugand un join trivial.

Id-urile pentru utilizatori sunt numere, dar restul sunt VARCHAR(64) cu niste validari facuta in cod prin regex-uri. Ar fi mai bine sa avem task_id ca numar si task_name ca string absolut peste tot. task_name se poate obtine foarte usor din task_id adaugand un join trivial.

MySQL *nu* face 'index pe hash-uri':http://dev.mysql.com/doc/refman/5.1/en/create-index.html pentru tabele pe disc (doar pentru tabele din memorie). MySQL sorteaza id-urile alfabetic tinand cont de colatii (latin2 pentru noi). Tinand string-uri peste tot crestem dimensiunile tabelelor, iar asta este oribil pentru tabele de genul ia_score sau ia_job. S-ar merita de facut niste teste de performanta, se poate compara un tabel de scor exclusiv numeric cu unul plin de string-uri.

MySQL *nu* face index pe hash-uri *DOC LINK HERE* pentru tabele pe disc, el sorteaza id-urile tinand cont de colatii (latin2). Tinand string-uri peste tot crestem dimensiunile tabelelor, si asta este oribil pentru tabele de genul ia_score sau ia_job. S-ar merita de facut niste teste de performanta comparand un tabel de scor exclusiv numeric cu unul plin de string-uri.

h3. Securitatea, si magia din wiki