Proiect de atestat în PHP și MySQL: arhitectura, securitatea și ce te întreabă comisia

E cel mai serios dintre proiectele obișnuite de atestat: ai și bază de date, și interfață web, și cod de server. Pentru un elev care vrea să iasă din categoria „a făcut un site”, e alegerea care plătește — cu condiția să nu fie doar un formular care scrie într-un tabel.

Pagina asta e despre ce transformă un set de fișiere PHP într-o aplicație pe care o poți apăra, și despre partea pe care competiția o ignoră complet: securitatea.

Dacă încă alegi între tehnologii, pornește de la cum îți alegi tema de proiect. Cadrul general al examenului e în ghidul atestatului.

Pentru cine e potrivit

Merge dacă:

• ai făcut deja ceva HTML și înțelegi ce e o bază de date;
• tema cere date care se modifică — adăugare, editare, ștergere — nu doar afișare;
• ai timp din decembrie, nu din martie.

Nu merge dacă e primul tău contact cu programarea web. În cazul ăla, un proiect în HTML, CSS și JavaScript e alegerea onestă, iar dacă te interesează mai mult modelul de date decât interfața, un proiect în Access acoperă aceeași competență cu mai puțin risc.

Diferența față de un proiect în Access

Ambele sunt aplicații cu bază de date. Diferența e unde rulează și cine o poate folosi:

	Access	PHP + MySQL
Rulează	local, pe un calculator	pe un server, accesibil din rețea
Utilizatori simultani	practic unul	mai mulți
Interfața	generată de Access	scrisă de tine, în HTML
Cod de scris	puțin sau deloc	tot
Riscul la examen	fișierul nu se deschide	serverul nu pornește

Conceptele notate — entități, relații, normalizare, integritate — sunt aceleași. Dacă vrei să recapitulezi partea de proiectare a schemei, e în pagina de Access, iar SQL-ul e în baze de date și SQL și în interogări SQL.

Ce înseamnă „complet”: CRUD pe toate entitățile

Un proiect care doar afișează date dintr-o bază nu demonstrează mai mult decât un site static cu text. Nivelul așteptat e CRUD — cele patru operații, pe cel puțin entitatea principală:

• Create — formular de adăugare;
• Read — listare și pagină de detaliu, cu căutare și filtrare;
• Update — formular de editare, precompletat cu valorile existente;
• Delete — ștergere, cu confirmare.

Peste asta, două lucruri care ridică vizibil proiectul: autentificare (administrator vs. vizitator) și o interogare cu JOIN și agregare care produce ceva util — un raport, un clasament, un total pe categorii.

Arhitectura fișierelor

Structura care se explică singură în fața comisiei:

proiect/
├── index.php
├── config/
│   └── db.php              ← conexiunea, într-un singur loc
├── includes/
│   ├── header.php
│   └── footer.php
├── produse/
│   ├── lista.php
│   ├── adauga.php
│   ├── editeaza.php
│   └── sterge.php
├── auth/
│   ├── login.php
│   └── logout.php
├── css/
│   └── stil.css
├── baza/
│   └── proiect.sql         ← structura + datele de test
└── README.txt

Regula care contează: conexiunea la baza de date se scrie o singură dată, în config/db.php, și se include peste tot. Dacă ai datele de conectare copiate în opt fișiere, prima întrebare despre mentenanță te prinde descoperit.

Partea pe care competiția o ignoră: securitatea

Aici se câștigă diferența. Proiectele vândute gata făcute sunt, aproape fără excepție, scrise într-un stil dispărut din PHP de ani buni — și un evaluator care se pricepe vede asta imediat.

Interogările se scriu pregătite, nu lipite

Varianta pe care o vezi în tutorialele vechi:

$sql = "SELECT * FROM produse WHERE nume = '" . $_GET['nume'] . "'";

Cine scrie ' OR '1'='1 în câmpul de căutare primește tot tabelul. Cu un DROP în loc de OR, pierzi baza. Se numește injecție SQL și e singura problemă de securitate pe care o știe orice profesor de informatică.

Varianta corectă, cu interogare pregătită:

$stmt = $pdo->prepare("SELECT * FROM produse WHERE nume = ?");
$stmt->execute([$_GET['nume']]);
$produse = $stmt->fetchAll();

Valoarea nu mai ajunge niciodată lipită în textul interogării — e trimisă separat, deci nu poate schimba sensul comenzii. Toate interogările care folosesc date venite de la utilizator se scriu așa. Fără excepții, fără „la asta nu contează”.

Parolele nu se țin în clar

Dacă proiectul are autentificare, parola se stochează hașurată:

// la înregistrare
$hash = password_hash($parola, PASSWORD_DEFAULT);

// la autentificare
if (password_verify($parola_introdusa, $hash_din_baza)) { /* ... */ }

O coloană parola cu 1234 scris în ea, vizibilă în phpMyAdmin, e cel mai ușor punct de atac al unei prezentări. Costă trei linii să nu-l ai.

mysql_query() nu mai există

Funcțiile mysql_* au fost eliminate din PHP 7, deci un proiect scris cu ele nu rulează pe nimic modern. Folosește PDO (recomandat, funcționează cu mai multe baze de date) sau mysqli. Dacă ai copiat cod de pe un tutorial din 2012, ăsta e primul lucru de verificat.

Planul pe luni

Termenul de depunere e 1 mai, cu referatul profesorului îndrumător:

Când	Ce faci
Decembrie	Tema, entitățile și relațiile pe hârtie. Instalezi XAMPP și verifici că pornește
Ianuarie	Baza de date în phpMyAdmin, cu date de test. Conexiunea PDO
Februarie	CRUD complet pe entitatea principală. Aici e cea mai mare parte din muncă
Martie	Autentificare, căutare, interogarea cu JOIN, CSS
Aprilie	Documentația și repetiția prezentării
1 mai	Depunere

Februarie e luna critică. Dacă la 1 martie nu ai CRUD funcțional, redu domeniul — taie autentificarea și o entitate — în loc să continui cu un proiect pe care nu-l termini.

Ce livrezi: codul nu e de ajuns

Greșeala care strică cel mai des ziua examenului: predai folderul cu fișiere PHP și uiți baza de date. Codul fără bază nu face nimic — pe alt calculator, tabelele nu există.

Exportă din phpMyAdmin: selectezi baza → Export → SQL → salvezi proiect.sql, care conține și structura, și datele. Fișierul ăla merge în proiect, iar README.txt explică în trei rânduri cum se importă înapoi.

Deci livrezi:

1. Codul — folderul complet;
2. Baza — proiect.sql, exportat, nu presupus;
3. Documentația — cu diagrama relațiilor și justificarea tehnologiilor;
4. Prezentarea — maximum 30 de minute.

Ce te întreabă comisia

„De ce PHP și MySQL și nu o aplicație desktop?” Răspunsul bun leagă alegerea de temă: aplicația trebuie folosită de mai multe persoane, din locuri diferite, fără instalare pe fiecare calculator.

„Cum previi injecția SQL?” Dacă ai scris interogări pregătite peste tot, e cea mai ușoară întrebare din examen. Dacă nu, e cea mai grea.

„Cum ții parolele?” password_hash() la înregistrare, password_verify() la autentificare. Explică de ce hașurarea nu e criptare: nu se poate da înapoi, și nici nu trebuie.

„Arată-mi interogarea cu JOIN și explică-mi-o.” Alege-o dinainte și repet-o cu voce tare.

„Ce se întâmplă dacă doi utilizatori modifică aceeași înregistrare?” Întrebare de nota mare. N-ai nevoie de soluție implementată — ai nevoie să înțelegi că e o problemă reală și să spui ce s-ar putea face.

Cum decurge proba: prezentarea proiectului în fața comisiei.

Greșeli frecvente

• Baza de date nelivrată. Cea mai frecventă și cea mai ușor de evitat.
• Interogări construite prin concatenare. Vulnerabilitate manifestă, verificabilă în zece secunde de un evaluator curios.
• Parole în clar în tabelul de utilizatori.
• Cod copiat cu mysql_*. Nu rulează pe PHP modern.
• Datele de conectare duplicate în fiecare fișier.
• Fără validare pe server. Verificarea doar în JavaScript se ocolește dezactivând JavaScript.
• Portul 80 ocupat. Apache din XAMPP nu pornește dacă alt program ține portul. Se schimbă din httpd.conf pe 8080 — de aflat înainte de examen, nu în sala de examen.
• Căi absolute de tipul http://localhost/proiectul-meu/... scrise în cod. Se rup dacă folderul are alt nume pe alt calculator.
• Fără date de test. O aplicație cu tabele goale nu demonstrează nimic la prezentare.

Întrebări frecvente

Ce trebuie să instalez pentru un proiect PHP cu MySQL? Un pachet care conține Apache, PHP și MySQL sau MariaDB — XAMPP e cel mai folosit. Include și phpMyAdmin, de unde administrezi baza de date din browser.

PDO sau mysqli? Ambele sunt corecte și ambele suportă interogări pregătite. PDO e recomandat pentru că funcționează și cu alte baze de date, deci codul nu e legat de MySQL.

Trebuie să pun proiectul online? Nu. Se prezintă local, din XAMPP. Asigură-te doar că pornește pe alt calculator decât al tău.

Cum livrez baza de date? Export din phpMyAdmin în format SQL, salvat ca fișier în proiect. Conține și structura tabelelor, și datele de test, deci se poate importa înapoi oriunde.

Ce e injecția SQL și de ce contează la atestat? E situația în care date introduse de utilizator schimbă sensul unei interogări, pentru că au fost lipite direct în textul ei. Contează pentru că e cea mai cunoscută vulnerabilitate web și e o întrebare previzibilă la susținere. Se previne folosind interogări pregătite.

Pot folosi un framework, de exemplu Laravel? Regula o stabilește profesorul îndrumător. Pentru atestat, PHP simplu e de obicei preferabil: se vede clar ce ai scris tu, iar un framework aduce cod pe care ar trebui să-l poți explica.

Câte tabele trebuie să aibă baza? Nu există un număr impus. Trei-cinci tabele legate corect acoperă orice temă de liceu; important e ca relațiile să fie justificate, nu ca tabelele să fie multe.

De unde vin informațiile de aici

Cerința ca proiectul să fie un produs software însoțit de prezentarea și motivarea teoretică, termenul de depunere de 1 mai și referatul profesorului îndrumător finalizat cu admis sau respins sunt din Metodologia de organizare și desfășurare a examenului de atestare a competențelor profesionale ale absolvenților claselor de matematică-informatică și matematică-informatică, intensiv informatică, aprobată prin OMECI nr. 4.843/2009 și modificată prin OM nr. 3.009/2021.

Tehnologiile permise, nivelul tehnic așteptat și criteriile de notare nu sunt prevăzute în metodologie — se stabilesc de catedra de specialitate a liceului tău. Recomandările de aici sunt un punct de plecare pentru cazul în care nu ți s-a impus un format. Verifică întotdeauna cerința profesorului îndrumător.