hanibal Posted December 19, 2006 Report Posted December 19, 2006 Acest contor se poate implementa printr-un câmp din tabela corespunzatoare resursei respective din baza de date, un camp de tip „întreg fara semn cu valoare initiala 0” (în MySQL mediumint(9) este o alegere care acopera marea majoritate a situatiilor posibile). La accesarea respectivei resurse se va executa o interogare de tipul:UPDATE tabela SET citiri=citiri+1 WHERE id=$idunde „tabela” este tabela în cauza, „citiri” campul contor iar „id” campul cu proprietatile “primary index” si “auto increment” din tabela. Variabila $id va contine în mod evident identificatorul resursei respective.Problema unei astfel de implementari este faptul ca nu exista absolut nici o protectie în ce priveste accesarile consecutive efectuate de un acelasi vizitator (în cazul în care acesta executa “refresh”, de exemplu, sau în cazul în care pur si simplu uita ca a vizitat pagina respectiva si o acceseaza din nou).Solutia pentru a contoriza o singura accesare pentru fiecare vizitator este retinerea într-un vector a identificatorilor resurselor vizitate si consultarea lui în momentul actualizarii contorului de vizite. Acest vector trebuie retinut neaparat ca variabila de sesiune pentru a-si pastra continutul pe toata durata vizitei efectuate de un anume utilizator. Implementarea în cod ar putea arata cam asa:session_register(“ids”);if (!in_array($id,$ids)){$ids[]=$id;mysql_query(“UPDATE tabela SET citiri=citiri+1 WHERE id=”.$id) or die(mysql_error());}Aceasta solutie nu rezolva problema revenirii unui anume utilizator pe pagina în cadrul unei alte vizite. De exemplu, daca X citeste articolul Ak astazi si revine peste 2 zile, citindu-l din nou, se vor contoriza 2 accesari distincte ale articolului respectiv. O solutie perfecta care sa remedieze si aceasta problema nu se poate pune în practica, ci numai solutii partial eficiente (care presupun din start existenta unei marje de eroare).credits:http://www.php.maelvi.ro :@ Quote