Ce este CRUD? Create, Read, Update, Delete explicate

CRUD înseamnă create, read, update și delete — cele patru lucruri de bază pe care le face o aplicație cu datele stocate. Adăugarea unui client nou este create, vizualizarea listei de clienți este read, schimbarea numărului lui de telefon este update, iar ștergerea lui este delete. Majoritatea aplicațiilor de business — CRM-uri, sisteme de rezervări, trackere de inventar, panouri de administrare — sunt în mare parte CRUD, cu reguli și un layout bun deasupra.

De ce contează când construiești cu AI

CRUD este vocabularul care transformă o idee vagă de aplicație într-o cerere precisă. „O aplicație pentru gestionarea furnizorilor noștri” lasă AI-ul să ghicească. „Creează, listează, editează și șterge furnizori, cu următoarele câmpuri” îi spune exact ce ecrane, operații din baza de date și rute de server să construiască.

Te ajută și ca listă de verificare la testare. Pentru fiecare tip de înregistrare din aplicație poți pune patru întrebări: pot adăuga una, o pot vedea, o pot modifica și o pot elimina — și pot face fiecare lucru doar cei potriviți? Un număr surprinzător de mare de aplicații construite cu AI pot crea înregistrări, dar nu le pot edita, sau lasă pe oricine să șteargă orice.

O analogie din viața de zi cu zi: o cutie cu fișe de rețete

Imaginează-ți o cutie cu fișe de rețete pe un raft din bucătărie.

• Create: scrii o fișă nouă și o pui la locul ei.
• Read: răsfoiești cutia sau scoți fișa pentru lasagna.
• Update: tai „200g brânză” și scrii „250g”.
• Delete: scoți o fișă și o arunci.

Acum adaugă reguli: doar șeful bucătăriei poate arunca fișe, fiecare fișă trebuie să aibă un titlu, iar nimeni nu poate pune două fișe cu același nume. Asta este o aplicație CRUD cu validare și permisiuni — ceea ce sunt de fapt cele mai multe aplicații reale.

Cum apare CRUD în fiecare strat

Fiecare operație apare pe ecran, pe server și în baza de date. Să le vezi una lângă alta explică mult din modul în care sunt construite aplicațiile.

Ecranul este frontend-ul, cererea API este modul în care frontend-ul vorbește cu backend-ul, iar SQL-ul este modul în care backend-ul vorbește cu baza de date. Dacă aceste cuvinte sunt noi, vezi ce este un API și ce este o bază de date.

Un exemplu practic: un tracker de echipamente de împrumut

Departamentul media al unei școli împrumută camere și microfoane elevilor și pierde mereu urma echipamentelor. Vor o aplicație simplă.

Înregistrările. Două tipuri de lucruri: echipamente (nume, tip, număr de serie, stare) și împrumuturi (ce echipament, ce elev, data ieșirii, data scadentă, data returnării).

CRUD pentru echipamente:

• Create: personalul adaugă o cameră nouă cu numărul ei de serie. Regulă: numerele de serie trebuie să fie unice.
• Read: o listă cu toate echipamentele, filtrabilă după tip și după „disponibil acum”; o pagină de detalii cu istoricul împrumuturilor unui articol.
• Update: schimbi starea în „necesită reparație”.
• Delete: de obicei nu este o ștergere reală. Dacă o cameră cu 30 de împrumuturi trecute este ștearsă, înregistrările de împrumut își pierd legătura. În schimb, o marchezi „retrasă”, ca să dispară din lista celor disponibile, dar istoricul ei rămâne. Asta se numește soft delete.

CRUD pentru împrumuturi:

• Create: înregistrezi un articol împrumutat unui elev. Regulă: nu poți împrumuta un articol care este deja împrumutat.
• Read: „împrumuturi restante” — o listă unde data scadentă a trecut și nu există dată de returnare.
• Update: înregistrezi data returnării când articolul revine.
• Delete: doar personalul, pentru împrumuturi introduse greșit.

Permisiuni. Elevii pot citi ce este disponibil; doar personalul poate crea, actualiza sau șterge. Aceste verificări rulează pe server, nu doar ascunzând butoane.

Asta este întreaga aplicație. Părțile interesante — fără împrumut dublu, o listă cu întârzieri, un istoric pentru fiecare articol — sunt reguli și interogări peste CRUD-ul simplu.

Termeni cheie

• Înregistrare (rând): un element, de exemplu un furnizor sau un împrumut.
• Entitate / resursă: un tip de înregistrare, de exemplu „furnizori”. Fiecare primește de obicei propriul tabel și propriul set de ecrane CRUD.
• Validare: verificări ale datelor introduse — câmpuri obligatorii, e-mail valid, cantitate pozitivă. Se face în formular și pe server, pentru siguranță.
• Soft delete: marcarea unei înregistrări ca ștearsă sau arhivată în loc să fie eliminată, ca istoricul și legăturile să rămână.
• Paginare: afișarea unei liste lungi câte o pagină, ca aplicația să rămână rapidă.
• Jurnal de audit: o evidență a cine a creat, modificat sau șters ce și când.
• Panou de administrare: un set de ecrane CRUD pentru ca personalul să gestioneze datele unei aplicații.

Greșeli și concepții greșite frecvente

• Uitarea uneia dintre cele patru. Aplicațiile ajung adesea cu create și read, dar fără edit, așa că fiecare greșeală de scriere înseamnă ștergere și reintroducere. Verifică toate patru pentru fiecare entitate.
• Ștergeri care strică lucruri. Ștergerea unui client care are facturi poate lăsa facturi orfane sau șterge istoricul. Decide pentru fiecare entitate: blochezi ștergerea, faci soft delete sau ștergi și înregistrările legate.
• Permisiuni doar în interfață. Ascunderea butonului de ștergere nu oprește pe cineva să trimită cererea DELETE. Serverul trebuie să verifice cine întreabă.
• Actualizare după ID fără verificarea proprietății. Dacă utilizatorul A poate edita /api/notes/42 schimbând un număr din URL, poate edita nota utilizatorului B. Fiecare update și delete trebuie să confirme că înregistrarea aparține solicitantului.
• Fără confirmare la ștergere. Un singur clic greșit nu ar trebui să distrugă date. Cere un pas de confirmare sau o anulare.
• „CRUD înseamnă simplu, deci nu merită construit.” Multe produse valoroase sunt aplicații CRUD care se potrivesc fluxului de lucru mai bine decât un instrument generic.

Ce să ceri constructorului tău de aplicații cu AI

Folosește acest model pentru fiecare entitate, pe rând:

Creează o funcție pentru furnizori cu listă, creare, editare și ștergere. Câmpuri: nume (obligatoriu), e-mail de contact (e-mail valid), telefon, categorie (una dintre: alimente, ambalaje, curățenie), note. Vizualizare listă cu căutare după nume și filtrare după categorie, 20 pe pagină. Cere confirmare înainte de ștergere; dacă un furnizor are comenzi, arhivează în loc să ștergi. Doar personalul autentificat poate crea, edita sau arhiva — aplică asta pe server.

Apoi testează toate cele patru operații, ca utilizator permis și ca cineva care nu ar trebui să aibă acces. Odată ce o entitate funcționează, adaugă-o pe următoarea. Cum construiești un instrument intern arată cum ecranele CRUD devin o aplicație completă de administrare, iar ce este Postgres explică baza de date pe care stau de obicei aceste aplicații.

Aplicații CRUD în Mythex

Aplicațiile CRUD sunt una dintre lucrurile la care constructorii de aplicații cu AI se descurcă cel mai bine, iar Mythex nu face excepție. Cere în chat entitatea și câmpurile ei, iar Mythex atașează proiectului o bază de date Postgres, creează tabelul și construiește ecranele de listă, formular și detalii într-o previzualizare live; apoi poți rula /test ca să verifici fluxul. Documentația are o rețetă pentru aplicații CRUD cu un prompt de start, iar constructorul de instrumente interne și șabloanele de dashboard sunt locuri bune de început.

Întrebări