Cum adaugi o bază de date în aplicația ta (fără să pierzi date mai târziu)
Pentru a adăuga o bază de date în aplicația ta, alege o bază de date relațională gestionată (Postgres este alegerea obișnuită), păstrează șirul de conectare într-un secret de pe server, creează un tabel pentru fiecare tip de lucru pe care îl stochează aplicația și fă ca backend-ul — niciodată browserul — să citească și să scrie în ea. Dacă construiești cu un constructor de aplicații bazat pe AI, de obicei poți spune pur și simplu „salvează asta într-o bază de date”, iar agentul creează tabelele și codul; rolul tău este să descrii clar datele și să verifici că acestea chiar persistă.
Acest ghid acoperă când ai nevoie de o bază de date, principalele opțiuni, cum îți descrii datele și greșelile care duc la pierderea sau scurgerea datelor.
Când are nevoie aplicația ta de o bază de date
Ai nevoie de o bază de date când aplicația trebuie să țină minte ceva după ce pagina este închisă sau să partajeze date între oameni. Semne tipice:
- Vizitatorii trimit ceva: un formular, o înscriere, o rezervare, o comandă
- Utilizatorii au conturi cu conținut salvat propriu
- Un administrator trebuie să vadă sau să editeze ce au creat alții
- Vrei rapoarte sau numărători în timp
Nu ai nevoie de una pentru un site static în care toată lumea vede același conținut, cum ar fi un portofoliu sau o pagină de prezentare simplă. Dacă nu ești sigur ce este de fapt o bază de date, citește mai întâi ce este o bază de date.
Opțiunile tale
| Opțiune | Ce este | Potrivită pentru | Compromisuri |
|---|---|---|---|
| Bază de date integrată din constructorul de aplicații | O bază de date creată și conectată pentru proiectul tău | Majoritatea aplicațiilor construite cu un constructor AI | Legată de hostingul acelei platforme; exportul și copiile de rezervă depind de platformă |
| Postgres sau MySQL gestionat | O bază de date relațională găzduită, pe care o achiziționezi separat | Aplicații pe care le găzduiești singur sau pe care le folosesc mai multe servicii | Gestionezi chei, limite de conexiuni și planuri |
| Backend-as-a-service | Bază de date plus autentificare, stocare și API-uri într-un singur produs | Aplicații orientate spre frontend care vor autentificare gata făcută | Mai multe concepte specifice furnizorului de învățat |
| Bază de date document (NoSQL) | Stochează documente flexibile, asemănătoare JSON | Date foarte neregulate | Relațiile și rapoartele sunt mai greu de făcut |
| O foaie de calcul ca bază de date | Google Sheets sau similar, prin API | Unelte interne mici, prototipuri | Lentă, fără constrângeri reale, se strică la editări simultane |
Pentru majoritatea aplicațiilor web mici și medii, o bază de date relațională precum Postgres este alegerea potrivită. Este bună la relații (un client are mai multe comenzi), păstrează datele consecvente și îți permite să pui întrebări mai târziu cu SQL. Vezi ce este Postgres pentru o prezentare în limbaj simplu.
Descrie-ți datele înainte să construiești
Cel mai util lucru pe care îl poți face este să notezi lucrurile pe care le stochează aplicația și cum sunt legate între ele. Nu ai nevoie de jargon de baze de date. Pentru o aplicație de rezervări:
- Clienți: nume, e-mail, telefon
- Servicii: nume, durată, preț
- Rezervări: ce client, ce serviciu, ora de începere, status (în așteptare, confirmată, anulată)
Asta înseamnă trei tabele. „Ce client” și „ce serviciu” devin legături (chei străine) între ele. A le avea corect de la început contează mult mai mult decât orice alegere tehnologică, pentru că schimbarea formei datelor care au deja rânduri reale este mai grea decât schimbarea unui layout de pagină.
Câteva reguli practice:
- Un tabel pentru fiecare tip de lucru. Nu băga comenzile într-o coloană text din tabelul clienților.
- Dă fiecărui rând un ID și o dată de creare. Le vei dori mai târziu.
- Folosește tipuri corecte. Datele ca date, banii ca sume în cenți întregi sau ca tip zecimal, nu ca text.
- Marchează câmpurile obligatorii ca obligatorii. Lasă baza de date să respingă datele greșite, nu doar formularul.
Exemple de prompturi
Începe cu o funcționalitate pe rând, în loc să arunci o schemă întreagă:
Adaugă o bază de date la această aplicație. Creează un tabel de rezervări cu numele clientului, e-mailul, serviciul, ora de început și statusul (în așteptare, confirmată, anulată; implicit în așteptare). Salvează trimiterile din formularul de rezervare în el, afișează un mesaj de succes și adaugă o pagină de administrare care listează rezervările, de la cea mai nouă.
Apoi extinde-l:
Adaugă un tabel de servicii (nume, durată în minute, preț în cenți). Înlocuiește câmpul liber pentru serviciu din rezervări cu o legătură către servicii și migrează rezervările existente fără să ștergi nimic.
Și apoi întărește-l:
Asigură-te că toate citirile și scrierile în baza de date se fac pe server. Browserul nu trebuie să primească niciodată șirul de conectare la baza de date. Validează e-mailul și ora de început pe server înainte de inserare.
Pas cu pas
- Listează-ți datele așa cum s-a arătat mai sus: lucruri, câmpuri, legături între ele.
- Creează baza de date. Într-un constructor AI, cere-o în chat. În altă parte, creează o instanță Postgres gestionată și copiază șirul de conectare.
- Stochează șirul de conectare ca secret (o variabilă de mediu pe server), niciodată în cod. Vezi variabilele de mediu și secretele.
- Creează tabelele. Folosește migrații, adică scripturi versionate care schimbă schema, ca schimbările să fie repetabile și reversibile.
- Construiește rutele de server care creează, citesc, actualizează și șterg rânduri (CRUD). Browserul apelează aceste rute; niciodată nu vorbește direct cu baza de date.
- Conectează interfața la aceste rute: formulare care salvează, liste care se încarcă, stări goale când nu există încă nimic.
- Testează persistența. Trimite ceva, reîncarcă pagina, deschide-o într-un alt browser. Dacă datele nu sunt acolo, nu au fost salvate în baza de date.
- Verifică accesul. Autentifică-te cu un al doilea utilizator și confirmă că nu poți vedea sau edita datele primului.
- Publică, apoi testează din nou pe adresa live, deoarece aplicația publicată poate folosi o conexiune diferită față de previzualizare.
Greșeli frecvente
- Salvezi în browser și crezi că e salvat. localStorage pare să funcționeze până când cineva deschide aplicația pe alt dispozitiv. Testează întotdeauna într-un al doilea browser.
- Pui șirul de conectare în codul frontend. Oricine poate citi codul frontend. Asta îi dă acces la toată baza ta de date.
- Fără verificări de acces. „Arată-mi comenzile” trebuie să filtreze după utilizatorul logat, pe server, nu în interfață. Este cea mai frecventă vulnerabilitate de securitate la aplicațiile construite cu AI; lista de verificare de securitate pentru aplicațiile construite cu AI o acoperă.
- Schimbări distructive de schemă. Cererea de a „redenumi tabelul” sau de a „schimba structura” poate șterge și recrea tabelul. Când există date reale, spune: „migrează rândurile existente, nu șterge nimic”.
- Stocarea fișierelor în baza de date. Imaginile și PDF-urile aparțin stocării de fișiere, iar în tabel rămâne doar URL-ul sau cheia lor. Vezi cum adaugi încărcări de fișiere.
- Fără copii de rezervă. Află cum face platforma copii de rezervă și cum le restaurezi înainte să ai clienți.
Listă de verificare
- Fiecare tip de lucru are propriul tabel, cu un ID și o dată de creare
- Câmpurile obligatorii și tipurile sunt impuse de baza de date
- Șirul de conectare există doar în secretele de pe server
- Toate citirile și scrierile trec prin rutele de server
- Fiecare utilizator poate citi și modifica doar propriile rânduri
- Datele supraviețuiesc unei reîncărcări și apar într-un alt browser
- Schimbările de schemă folosesc migrații și păstrează rândurile existente
- Știi cum funcționează copiile de rezervă și restaurarea
- Aplicația live a fost testată după publicare
Adăugarea unei baze de date în Mythex
În Mythex, fiecare proiect poate primi propria bază de date Postgres dedicată, atât în planul Free, cât și în Pro. De obicei nu trebuie să apeși un buton separat de „atașare”: cere-o în chat („salvează adresele de e-mail din lista de așteptare într-o bază de date”) sau scrie /database, iar datele de conectare sunt injectate în spațiul de lucru și în aplicația publicată. Setările proiectului arată dacă o bază de date este activă.
Baza de date intră în repaus după 5 minute de inactivitate și se trezește la următoarea cerere. Utilizarea publicată se taxează pentru timpul în care a fost efectiv trează, din același sold de credite pe care îl folosești pentru construire. Dacă adaugi o bază de date după ce ai publicat deja, publică din nou, ca aplicația live să o preia.
Vezi Database și rețeta Construiește o aplicație CRUD din documentație. Pentru partea de autentificare a datelor pe utilizator, citește cum adaugi autentificare în aplicația ta.
Întrebări
Am nevoie de o bază de date pentru aplicația mea?
Ai nevoie de una de îndată ce aplicația trebuie să țină minte ceva după ce pagina se închide sau să partajeze date între utilizatori: înscrieri, comenzi, rezervări, postări sau setări. Un site static care arată același conținut tuturor nu are nevoie de una.
Ce bază de date ar trebui să folosesc pentru o aplicație web mică?
O bază de date relațională, precum Postgres, este o alegere sigură pentru majoritatea aplicațiilor web mici. Gestionează bine utilizatorii, comenzile, relațiile și rapoartele, este larg suportată și, la scară mică, rareori o depășești.
Pot stoca datele în browser în loc de o bază de date?
Stocarea din browser, precum localStorage, există doar pe un dispozitiv, într-un singur browser, iar utilizatorul o poate șterge oricând. Este în regulă pentru preferințe, cum ar fi alegerea temei, dar nu pentru date pe care tu sau alți utilizatori trebuie să le vedeți mai târziu.
Include Mythex o bază de date?
Da. Un proiect Mythex poate avea propria bază de date Postgres dedicată, atât în planul Free, cât și în Pro. O ceri în chat sau folosind comanda /database, iar datele de conectare sunt injectate automat. Utilizarea se plătește din același sold de credite ca și construirea.