Ce presupune, dincolo de „stocarea datelor"
O bază de date bine proiectată ține cont de cum vor crește datele în timp și cum vor fi interogate — o structură greșită de la început devine greu de reparat după ce sistemul e deja în producție cu date reale.
Situații frecvente
- Proiectare bază de date, pentru o aplicație nouă.
- Optimizare a unei baze de date lente.
- Migrare de la un sistem vechi.
- Integrare cu alte sisteme existente.
Normalizare — cât de departe merge, de fapt
Normalizarea, adică eliminarea datelor redundante prin separarea în tabele corelate, previne inconsistențele, dar normalizarea excesivă poate încetini interogările complexe prin prea multe legături între tabele — un proiectant bun știe unde să denormalizeze intenționat, pentru performanță.
Discută explicit cu dezvoltatorul nivelul de normalizare țintă și unde se justifică abateri, mai degrabă decât să presupui că „mai normalizat" înseamnă automat „mai bine proiectat".
Indexare — diferența dintre o interogare rapidă și una care blochează aplicația
Un index pus pe coloana greșită nu ajută deloc, iar prea multe indexuri încetinesc scrierile, pentru că fiecare adăugare sau modificare trebuie să actualizeze toate indexurile aferente — strategia de indexare trebuie gândită în funcție de interogările reale ale aplicației.
Cere un plan de execuție pentru interogările critice înainte de lansare — un plan care arată scanare completă de tabel pe un tabel mare e semnul clar că lipsește un index necesar.
Migrarea de la un sistem vechi — ce se pierde ușor
La migrarea dintr-un sistem legacy, cea mai frecventă pierdere e integritatea referențială implicită — reguli care existau doar în codul vechi al aplicației, nescrise nicăieri în baza de date, și care dispar tăcut dacă nu sunt identificate explicit înainte de migrare.
Rulează migrarea întâi pe o copie completă a datelor reale, nu pe date de test generate — abia pe date reale ies la iveală valorile neconforme și cazurile speciale care blochează scriptul de migrare în producție.
Alegerea motorului de bază de date — nu toate fac același lucru
MySQL și MariaDB rămân alegerea implicită pentru aplicații web tradiționale, dar PostgreSQL oferă tipuri de date și interogări avansate care contează pentru aplicații cu cerințe speciale de la bun început.
Schimbarea motorului de bază de date după ce aplicația e deja în producție e costisitoare — decizia se ia la începutul proiectului, ținând cont de cerințele pe termen lung, nu doar de ce cunoaște echipa de dezvoltare la momentul respectiv.
Proiectarea schemei pentru o aplicație nouă — de unde se pornește
Un model entitate-relație desenat înainte de prima linie de cod economisește refactorizări costisitoare mai târziu — schimbarea structurii unei tabele după ce aplicația are date reale în producție înseamnă migrări suplimentare, riscante și lente.
Discută explicit volumul de date așteptat la un an și la trei ani de la lansare — o schemă gândită pentru câteva mii de rânduri se comportă complet diferit la milioane de rânduri.
Chei primare, chei străine și integritate — de ce nu se sar peste
O bază de date fără constrângeri de cheie străină „funcționează" până când o eroare de aplicație lasă în urmă înregistrări orfane — constrângerile la nivel de bază de date sunt ultima linie de apărare, chiar dacă aplicația validează deja datele.
Alegerea între chei primare auto-increment și identificatori unici influențează performanța indexurilor și posibilitatea de a sincroniza date între sisteme distribuite — o decizie tehnică simplă în aparență, cu efecte greu de întors ulterior.
Optimizarea unei baze de date deja lente
Înainte de a cumpăra hardware mai puternic, verifică interogările repetitive inutil, acolo unde aplicația face sute de interogări mici când una singură, bine scrisă, ar fi suficientă — de multe ori cauza reală a lentorii e în cod, nu în serverul de bază de date.
Monitorizarea interogărilor lente pe o perioadă reală de trafic, nu doar în teste sintetice, arată exact unde merită investit timpul de optimizare, în loc să optimizezi la întâmplare tabele care oricum funcționează bine.
Integrarea cu alte sisteme — ce trebuie clarificat din start
Când baza de date nouă trebuie să sincronizeze date cu un ERP, un CRM sau alt sistem extern, stabilește din capul locului cine e sursa de adevăr pentru fiecare tip de dată — altfel apar conflicte greu de depanat când ambele sisteme modifică aceeași informație.
Sincronizarea în timp real e mai complexă de întreținut decât o sincronizare periodică prin job programat, dar uneori e singura opțiune viabilă — discută explicit ce nivel de actualitate a datelor chiar are nevoie aplicația.
Livrabile de cerut la finalul unui proiect de dezvoltare
Cere diagrama finală a schemei, nu doar cea din faza de proiectare, scripturile de migrare versionate și o listă a indexurilor create, cu motivația fiecăruia — documentație fără de care orice dezvoltator ulterior pornește de la zero.
Un set de interogări de test pentru cazurile limită — volum mare, caractere speciale, valori nule — ar trebui livrat alături de baza de date, nu improvizat abia când apare prima problemă în producție.