Vad är CRUD? Create, Read, Update, Delete förklarat

CRUD står för create, read, update och delete – de fyra grundläggande sakerna en app gör med lagrad data. Att lägga till en ny kund är create, att visa kundlistan är read, att ändra deras telefonnummer är update och att ta bort dem är delete. De flesta affärsappar – CRM, bokningssystem, lagerverktyg, adminpaneler – består till stor del av CRUD med regler och en bra layout ovanpå.

Varför det spelar roll när du bygger med AI

CRUD är det ordförråd som förvandlar en vag appidé till en precis förfrågan. "En app för att hantera våra leverantörer" lämnar AI:n att gissa. "Skapa, lista, redigera och ta bort leverantörer med dessa fält" talar om exakt vilka skärmar, databasoperationer och serverrutter som ska byggas.

Det ger dig också en checklista för testning. För varje typ av post i din app kan du ställa fyra frågor: kan jag lägga till en, se dem, ändra en och ta bort en – och kan bara rätt personer göra var och en? Ett överraskande antal AI-byggda appar kan skapa poster men inte redigera dem, eller låter vem som helst ta bort vad som helst.

En vardaglig liknelse: en receptkortlåda

Tänk dig en låda med receptkort på en köksbänk.

• Create: skriv ett nytt kort och lägg det i lådan.
• Read: bläddra i lådan, eller ta fram kortet för lasagne.
• Update: stryk "200 g ost" och skriv "250 g".
• Delete: ta ut ett kort och kasta det.

Lägg nu till regler: bara kökschefen får kasta kort, varje kort måste ha en titel, och ingen får lägga in två kort med samma namn. Det är en CRUD-app med validering och behörigheter – vilket de flesta riktiga appar är.

Hur CRUD syns i varje lager

Varje operation finns i skärmen, servern och databasen. Att se dem sida vid sida förklarar mycket om hur appar byggs.

Skärmen är frontend, API-förfrågan är hur frontend pratar med backend, och SQL är hur backend pratar med databasen. Om orden är nya, se vad ett API är och vad en databas är.

Ett praktiskt exempel: ett lånesystem för utrustning

En skolas mediaavdelning lånar ut kameror och mikrofoner till elever och tappar hela tiden bort koll på dem. De vill ha en enkel app.

Posterna. Två slags saker: utrustning (namn, typ, serienummer, skick) och lån (vilken utrustning, vilken elev, datum ut, förfallodatum, datum för återlämning).

CRUD för utrustning:

• Create: personalen lägger till en ny kamera med serienummer. Regel: serienummer måste vara unika.
• Read: en lista över all utrustning, filtrerbar på typ och på "tillgänglig nu"; en detaljsida som visar lånehistoriken för en enskild artikel.
• Update: ändra skicket till "behöver lagas".
• Delete: vanligtvis inte en riktig borttagning. Om en kamera med 30 tidigare lån tas bort förlorar lånposterna sin koppling. Markera den i stället som "utrangerad" så att den försvinner från listan över tillgängliga, men historiken finns kvar. Detta kallas en mjuk borttagning.

CRUD för lån:

• Create: registrera att en artikel lånas ut till en elev. Regel: en artikel som redan är utlånad kan inte lånas ut igen.
• Read: "försenade lån" – en lista där förfallodatumet har passerat och det inte finns något återlämningsdatum.
• Update: registrera återlämningsdatumet när artikeln kommer tillbaka.
• Delete: endast personal, för lån som registrerats av misstag.

Behörigheter. Elever kan läsa vad som finns tillgängligt; endast personal kan skapa, uppdatera eller ta bort. Dessa kontroller körs på servern, inte bara genom att dölja knappar.

Det är hela appen. De intressanta delarna – ingen dubbelutlåning, en lista över försenade lån, en historik per artikel – är regler och frågor ovanpå vanlig CRUD.

Nyckeltermer

• Post (rad): en enskild sak, till exempel en leverantör eller ett lån.
• Entitet / resurs: en typ av post, till exempel "leverantörer". Varje entitet får oftast en egen tabell och en egen uppsättning CRUD-skärmar.
• Validering: kontroller av indata – obligatoriska fält, giltig e-postadress, positivt antal. Gör det i formuläret för bekvämlighet och på servern för säkerhet.
• Mjuk borttagning: att markera en post som borttagen eller arkiverad i stället för att ta bort den, så att historik och kopplingar består.
• Paginering: att visa en lång lista en sida i taget, så att appen förblir snabb.
• Granskningslogg: en registrering av vem som skapade, ändrade eller tog bort vad, och när.
• Adminpanel: en uppsättning CRUD-skärmar för personal att hantera en apps data.

Vanliga misstag och missuppfattningar

• Att glömma en av de fyra. Appar levereras ofta med create och read men ingen redigering, så varje stavfel kräver att man tar bort och skriver in på nytt. Kontrollera alla fyra för varje entitet.
• Borttagningar som bryter saker. Att ta bort en kund som har fakturor kan lämna föräldralösa fakturor eller radera historik. Bestäm per entitet: blockera borttagningen, gör en mjuk borttagning, eller ta bort relaterade poster också.
• Behörigheter bara i gränssnittet. Att dölja knappen Ta bort hindrar inte att någon skickar en DELETE-förfrågan. Servern måste kontrollera vem som frågar.
• Uppdatering via ID utan ägarkontroll. Om användare A kan redigera /api/notes/42 genom att ändra ett nummer i URL:en kan de redigera användare B:s anteckning. Varje uppdatering och borttagning måste bekräfta att posten tillhör den som begär ändringen.
• Ingen bekräftelse vid borttagning. Ett enda felklick ska inte förstöra data. Be om ett bekräftelsesteg eller en ångra-funktion.
• "CRUD betyder enkelt, så det är inte värt att bygga." Många värdefulla produkter är CRUD-appar som passar ett arbetsflöde bättre än ett generiskt verktyg gör.

Vad du ska be din AI-byggare om

Använd det här mönstret för varje entitet, en i taget:

Skapa en funktion för leverantörer med lista, skapa, redigera och ta bort. Fält: namn (obligatoriskt), kontakt-e-post (giltig e-postadress), telefon, kategori (en av: livsmedel, förpackningar, rengöring), anteckningar. Listvy med sökning på namn och filter på kategori, 20 per sida. Be om bekräftelse innan borttagning; om en leverantör har beställningar ska den arkiveras i stället för att tas bort. Endast inloggad personal kan skapa, redigera eller arkivera – kontrollera detta på servern.

Testa sedan alla fyra operationerna, som en behörig användare och som någon som inte borde ha åtkomst. När en entitet fungerar, lägg till nästa. Hur du bygger ett internt verktyg visar hur CRUD-skärmar blir en komplett adminapp, och vad Postgres är förklarar databasen de flesta av dessa appar ligger på.

CRUD-appar i Mythex

CRUD-appar är en av de saker som AI-appbyggare gör bäst, och Mythex är inget undantag. Be i chatten om entiteten och dess fält, så kopplar Mythex en Postgres-databas till projektet, skapar tabellen och bygger lista-, formulär- och detaljskärmar i en levande förhandsvisning; därefter kan du köra /test för att kontrollera flödet. Dokumentationen har ett recept för CRUD-app med en startprompt, och verktyget för interna appar och dashboard-mallarna är bra ställen att börja på.

Frågor