Când Aplicația Ta Creată cu AI Are Cu Adevărat Nevoie de o Bază de Date Reală (Și Când Nu)

Ce Face de Fapt o Bază de Date?

Rolul unei baze de date este să se asigure că două persoane nu pot suprascrie sau distruge accidental munca celeilalte în timp ce folosesc aceeași aplicație — viteza, structura și căutarea complexă sunt doar efecte secundare ale rezolvării acestei singure probleme.

Ți-ai construit aplicația cu AI. Funcționează. Salvează date în fișiere sau într-un tabel. Totul pare în regulă.

Apoi se întâmplă unul din două lucruri:

1. Aplicația ta devine tot mai lentă de fiecare dată când cineva o folosește.
2. Doi utilizatori încearcă să o folosească în același timp și ceva se strică.

Niciuna dintre aceste defecțiuni nu este evidentă până nu e prea târziu. Ambele sunt probleme de bază de date deghizate.

Dacă folosești în continuare fișiere sau tabele, probabil că încă nu ai o bază de date. Și e în regulă. Dar ar trebui să cunoști semnele că urmează să ai nevoie de una.

Când E În Regulă Să Folosești Doar Fișiere În Loc de o Bază de Date?

Fișierele funcționează bine atâta timp cât ești singura persoană care folosește aplicația și modificările sunt rare — acesta e întregul test.

Site-ul de portofoliu al unui freelancer? Fișierele sunt perfecte. Un tracker personal de cheltuieli? Fișierele sunt bune. Un proiect de hobby cu un singur utilizator? Nu complica lucrurile.

Semne reale că fișierele funcționează:

• Doar o persoană folosește aplicația la un moment dat (sau utilizatorii sunt offline cât timp alții lucrează).
• Actualizezi datele rar (o dată pe zi, o dată pe săptămână, o dată pe lună).
• E acceptabil să pierzi ultimele 30 de secunde de muncă (constructorul tău poate încerca din nou pur și simplu).
• Fișierul de date e suficient de mic încât să poată fi trimis prin email (sub 10 MB).

Dacă toate cele patru sunt adevărate, rămâi la fișiere. Serios. Simplitatea e un avantaj, nu o limitare.

De Ce Devine Aplicația Mea Creată cu AI Tot Mai Lentă?

Aplicația ta încetinește pentru că fișierul în care salvează crește constant, iar constructorul tău încarcă întregul fișier în memorie de fiecare dată când trebuie să modifice ceva — un cost aproape imperceptibil la început, care devine dureros pe măsură ce fișierul crește.

Îl observi ca pe o senzație. Aplicația ta pare mai lentă decât era înainte. Un click pe un buton durează o secundă în plus. Căutarea e vizibil mai lentă. Nu ai schimbat codul — de ce e mai lentă? Iată tiparul:

1. Aplicația încarcă fișierul complet de date (100 de linii, rapid).
2. Utilizatorul adaugă o înregistrare (acum 101 linii).
3. Aplicația recitește întregul fișier pentru verificare (încă rapid).
4. După 2.000 de înregistrări, citirea fișierului durează 2 secunde.
5. După 10.000 de înregistrări, durează 20 de secunde.

Nu e exponențial, dar devine vizibil în jurul a 5.000 de înregistrări și devine dureros în jurul a 20.000.

Prima soluție (înainte să adaugi o bază de date): Cere-i constructorului tău să încarce datele la cerere. Încarcă doar înregistrările pe care le afișezi, sau doar coloanele pe care le arăți. Multe aplicații pot rămâne pe fișiere fiind mai inteligente în privința a ceea ce încarcă.

Când să treci la o bază de date: Ai mai mult de 50.000 de înregistrări de date, sau lentoarea persistă chiar și după optimizarea încărcărilor.

De Ce Mi-a Pierdut Aplicația Date Când Au Folosit-o Două Persoane Simultan?

Se întâmplă pentru că două persoane pot edita același fișier în același timp și aplicația nu are cum să știe asta — oricine salvează al doilea câștigă, iar modificările primei persoane dispar în tăcere. Se numește “scriere concurentă” (conflicting write), și e o eroare clasică de pierdere de date.

Ambele persoane văd propriile modificări pe ecran. Amândouă apasă “salvează.” Vei ști că se întâmplă asta dacă:

• Utilizatorii raportează din când în când date lipsă (mai ales dacă mai multe persoane sunt în aplicație în același timp).
• Utilizatorii raportează că văd cum modificările altor persoane sunt “anulate” fără nicio explicație.
• Doi utilizatori editează aceeași înregistrare și modificările uneia dintre persoane dispar.
• Primești mesaje de genul “jur că am adăugat asta ieri și acum a dispărut.”

Nu e vina aplicației. E o limitare a modului în care funcționează fișierele. Nu există o modalitate bună de a gestiona asta fără o bază de date.

Când să treci la o bază de date: De îndată ce două persoane folosesc aplicația în același timp, chiar dacă încă nu s-a defectat încă.

De Ce Nu Poate Aplicația Mea Să Facă Față Căutărilor Complexe Cu Fișiere?

Pentru că, în cazul fișierelor, constructorul tău trebuie să încarce și să filtreze manual fiecare set de date asociat, pas cu pas, în loc să pună o singură întrebare și să primească un singur răspuns — o bază de date face aceeași treabă în milisecunde printr-o singură interogare.

Să spunem că vrei să găsești “toate facturile neplătite ale clienților din California care nu au fost contactați în ultima săptămână.” Cu fișiere, constructorul tău trebuie să:

1. Încarce toate facturile.
2. Filtreze după unpaid = true.
3. Încarce toți clienții și să potrivească după ID.
4. Filtreze după state = “CA”.
5. Încarce toate înregistrările de contact și să potrivească după ID-ul clientului.
6. Filtreze după date > o săptămână în urmă.

Cu o bază de date, scrii o singură interogare și ea face toate astea în milisecunde.

Când să treci la o bază de date: Când constructorul tău spune “ar trebui să scriu cod personalizat ca să răspund la asta.” Sau când observi că aplicația face multă muncă doar ca să-ți arate date filtrate.

Ce Ar Trebui Să-i Spun Constructorului Meu Când Am Nevoie de o Bază de Date?

Spune-i clar ce nu merge bine și cere-i un plan — ceva de genul: “Aplicația devine [mai lentă/a avut date lipsă/are nevoie de căutări mai complexe]. Cred că ar trebui să adăugăm o bază de date. Cât de mare e schimbarea asta?”

Majoritatea constructorilor pot muta o aplicație de la fișiere la o bază de date în 1-2 zile pentru aplicații mici, câteva zile pentru cele mai mari. Procesul e:

1. Păstrează aplicația în mare parte la fel (utilizatorii nu vor vedea o schimbare majoră).
2. Conectează un backend de bază de date (încă arată ca fișiere pentru restul codului, dar dedesubt e o bază de date).
3. Testeaz-o din plin (pentru că mutarea datelor e o operațiune sensibilă).
4. Rulează ambele în paralel timp de o săptămână până când ești sigur.

Constructorul te-ar putea întreba:

• “Ar trebui să folosim PostgreSQL, MySQL, sau altceva?”
  • Răspunsul tău: “Cu ce te simți tu cel mai confortabil. Nu știu diferența, dar am încredere în tine.”
• “Asta va dura 3 zile. Merită?”
  • Răspunsul tău: “Dacă oricum trebuie să ne mutăm, mai devreme e mai bine decât mai târziu, când vor fi mai multe date.”
• “Ar trebui să migrăm datele vechi?”
  • Răspunsul tău: “Da, doar dacă sunt sub 100 de înregistrări, atunci un început nou e în regulă.”

Trebuie Să Înțeleg Eu Însumi Bazele de Date?

Nu — nu trebuie să știi ce e o bază de date, să înveți SQL, sau să compari PostgreSQL cu MySQL. Tot ce trebuie să-i spui constructorului tău este: “Două persoane pot folosi aplicația simultan fără să piardă munca uneia sau alteia.”

Atât. Constructorul tău poate alege baza de date. Una simplă precum SQLite (pentru o aplicație personală sau de echipă cu <10 utilizatori simultani) sau PostgreSQL (pentru orice e mai mare) — ambele fac treaba asta.

---

Cum Îmi Dau Seama Dacă Aplicația Mea Are Nevoie de o Bază de Date?

Bifează care dintre aceste patru situații ți se aplică — două sau mai multe căsuțe bifate înseamnă că e timpul să adaugi o bază de date acum.

• Lentoare: Aplicația se simțea mai rapidă acum 3 luni, se simte mai lentă acum. Fișierul de date are >20 MB sau >10.000 de înregistrări.
• Pierdere de date: Modificările cuiva au dispărut, sau mai mulți utilizatori au raportat editări lipsă.
• Complexitate: Vrei să pui întrebări de genul “arată-mi X filtrat după Y” iar constructorul spune “e greu de făcut asta cu fișiere.”
• Utilizatori: Mai mult de o persoană folosește aplicația în același timp (chiar și ocazional).

Dacă ai bifat două sau mai multe căsuțe, aplicația ta e pregătită pentru o bază de date.

Dacă ai bifat zero căsuțe, fișierele tale sunt în regulă. Păstrează-le. Simplitatea are valoare.

Dacă ai bifat o căsuță, întreabă-ți constructorul: “E suficient de rapid ca să trăiesc cu asta încă 6 luni?” Dacă da, așteaptă. Dacă nu, mută acum.