Hva er CRUD? Create, read, update og delete forklart

CRUD står for create, read, update og delete – de fire grunnleggende tingene en app gjør med lagrede data. Å legge til en ny kunde er create, å se kundelisten er read, å endre telefonnummeret deres er update, og å fjerne dem er delete. De fleste forretningsapper – CRM-er, bookingsystemer, lagersystemer, adminpaneler – er i stor grad CRUD med regler og et godt oppsett på toppen.

Hvorfor det betyr noe når du bygger med KI

CRUD er vokabularet som gjør en vag appidé om til en presis forespørsel. «En app for å administrere leverandørene våre» gjør at KI-en må gjette. «Create, list, edit og delete leverandører, med disse feltene» forteller den nøyaktig hvilke skjermer, databaseoperasjoner og serverruter den skal bygge.

Det gir deg også en sjekkliste for testing. For hver type post i appen din kan du stille fire spørsmål: kan jeg legge til en, se dem, endre en og fjerne en – og kan bare de riktige personene gjøre hver av dem? Et overraskende antall KI-bygde apper kan opprette poster, men ikke redigere dem, eller lar hvem som helst slette alt.

En hverdagslig analogi: en eske med oppskriftskort

Tenk deg en eske med oppskriftskort på en kjøkkenhylle.

• Create: skriv et nytt kort og legg det inn.
• Read: blad gjennom esken, eller ta frem kortet for lasagne.
• Update: strek over «200 g ost» og skriv «250 g».
• Delete: ta et kort ut og kast det.

Legg nå til regler: bare hovedkokken kan kaste kort, hvert kort må ha en tittel, og ingen kan legge inn to kort med samme navn. Da har du en CRUD-app med validering og tillatelser – og det er det de fleste ekte apper er.

Hvordan CRUD dukker opp i hvert lag

Hver operasjon finnes i skjermen, serveren og databasen. Å se dem side om side forklarer mye om hvordan apper bygges.

Skjermen er frontend, API-forespørselen er hvordan frontend snakker med backend, og SQL-en er hvordan backend snakker med databasen. Hvis disse ordene er nye, se hva et API er og hva en database er.

Et praktisk eksempel: en sporingsapp for utstyrslån

En skoles mediaavdeling låner ut kameraer og mikrofoner til elever, og mister stadig oversikten. De vil ha en enkel app.

Postene. To typer ting: utstyr (navn, type, serienummer, tilstand) og lån (hvilket utstyr, hvilken elev, dato ut, forfallsdato, dato returnert).

CRUD for utstyr:

• Create: ansatte legger til et nytt kamera med serienummeret. Regel: serienumre må være unike.
• Read: en liste over alt utstyr, filtrerbar på type og på «tilgjengelig nå»; en detaljside som viser lånehistorikken til én gjenstand.
• Update: endre tilstanden til «trenger reparasjon».
• Delete: vanligvis ikke en ekte sletting. Hvis et kamera med 30 tidligere lån slettes, mister lånepostene koblingen sin. I stedet markeres det som «utrangert», slik at det forsvinner fra listen over tilgjengelig utstyr, men historikken består. Dette kalles en myk sletting.

CRUD for lån:

• Create: registrer at en gjenstand lånes ut til en elev. Regel: du kan ikke låne ut en gjenstand som allerede er utlånt.
• Read: «forfalte lån» – en liste der forfallsdatoen har passert og det ikke finnes returdato.
• Update: registrer returdatoen når gjenstanden kommer tilbake.
• Delete: bare ansatte, for lån som er registrert ved en feil.

Tillatelser. Elever kan lese hva som er tilgjengelig; bare ansatte kan opprette, oppdatere eller slette. Disse sjekkene kjører på serveren, ikke bare ved å skjule knapper.

Det er hele appen. De interessante delene – ingen dobbeltutlån, en liste over forfalte lån, en historikk per gjenstand – er regler og spørringer på toppen av ren CRUD.

Nøkkelbegreper

• Post (rad): én gjenstand, for eksempel én leverandør eller ett lån.
• Entitet / ressurs: en type post, for eksempel «leverandører». Hver får vanligvis sin egen tabell og sitt eget sett med CRUD-skjermer.
• Validering: kontroller av input – påkrevde felt, gyldig e-post, positiv mengde. Gjør det i skjemaet for bekvemmelighet og på serveren for sikkerhet.
• Myk sletting: å markere en post som slettet eller arkivert i stedet for å fjerne den, slik at historikk og koblinger består.
• Paginering: å vise en lang liste en side av gangen, slik at appen forblir rask.
• Revisjonslogg: en oversikt over hvem som opprettet, endret eller slettet hva, og når.
• Adminpanel: et sett med CRUD-skjermer som ansatte bruker til å administrere en apps data.

Vanlige feil og misforståelser

• Å glemme en av de fire. Apper leveres ofte med create og read, men uten redigering, slik at hver skrivefeil betyr at man må slette og legge inn på nytt. Sjekk alle fire for hver entitet.
• Slettinger som ødelegger ting. Å slette en kunde som har fakturaer kan etterlate forlatte fakturaer eller viske ut historikk. Bestem per entitet: blokker slettingen, slett myk, eller slett relaterte poster også.
• Tillatelser bare i grensesnittet. Å skjule Slett-knappen hindrer ikke at noen sender DELETE-forespørselen. Serveren må sjekke hvem som spør.
• Oppdatering via ID uten eierskapssjekk. Hvis bruker A kan redigere /api/notes/42 ved å endre et tall i URL-en, kan de redigere bruker B sitt notat. Hver oppdatering og sletting må bekrefte at posten tilhører den som ber om endringen.
• Ingen bekreftelse ved sletting. Ett feiltrykk bør ikke ødelegge data. Be om et bekreftelsessteg, eller en angre-funksjon.
• «CRUD betyr grunnleggende, så det er ikke verdt å bygge.» Mange verdifulle produkter er CRUD-apper som passer en arbeidsflyt bedre enn et generisk verktøy gjør.

Hva du bør be KI-appbyggeren din om

Bruk dette mønsteret for hver entitet, én om gangen:

Lag en leverandører-funksjon med liste, opprett, rediger og slett. Felt: navn (påkrevd), kontakt-e-post (gyldig e-post), telefon, kategori (én av: mat, emballasje, rengjøring), notater. Listevisning med søk på navn og filter på kategori, 20 per side. Be om bekreftelse før sletting; hvis en leverandør har bestillinger, arkiver i stedet for å slette. Bare innloggede ansatte kan opprette, redigere eller arkivere – håndhev dette på serveren.

Test deretter alle fire operasjonene, som en bruker med tilgang og som någon som ikke skal ha tilgang. Når én entitet fungerer, legg til den neste. Hvordan du bygger et internt verktøy viser hvordan CRUD-skjermer blir til en komplett adminapp, og hva Postgres er forklarer databasen de fleste av disse appene ligger på.

CRUD-apper på Mythex

CRUD-apper er blant de tingene KI-appbyggere gjør best, og Mythex er intet unntak. Be om entiteten og feltene i chatten, så kobler Mythex en Postgres-database til prosjektet, oppretter tabellen og bygger liste-, skjema- og detaljskjermene i en levende forhåndsvisning; deretter kan du kjøre /test for å sjekke flyten. Dokumentasjonen har en CRUD-app-oppskrift med en startprompt, og byggeren for interne verktøy og dashbord-malene er gode steder å starte.

Spørsmål