Ratgeber

Was ist CRUD? Create, Read, Update, Delete einfach erklärt

CRUD steht für Create, Read, Update und Delete – die vier grundlegenden Dinge, die eine App mit gespeicherten Daten tut. Einen neuen Kunden anlegen ist Create, die Kundenliste ansehen ist Read, seine Telefonnummer ändern ist Update, und ihn entfernen ist Delete. Die meisten Geschäftsapps – CRMs, Buchungssysteme, Inventar-Tracker, Admin-Panels – bestehen größtenteils aus CRUD, mit Regeln und einem guten Layout obendrauf.

Warum es wichtig ist, wenn Sie mit KI bauen

CRUD ist das Vokabular, das eine vage App-Idee in eine präzise Anweisung verwandelt. „Eine App zur Verwaltung unserer Lieferanten“ lässt die KI raten. „Lieferanten anlegen, auflisten, bearbeiten und löschen, mit diesen Feldern“ sagt ihr genau, welche Bildschirme, Datenbankoperationen und Server-Routen sie bauen soll.

Es gibt Ihnen auch eine Checkliste zum Testen. Für jede Art von Datensatz in Ihrer App können Sie vier Fragen stellen: Kann ich einen anlegen, sie sehen, einen ändern und einen entfernen – und können nur die richtigen Personen jeweils das tun? Erstaunlich viele KI-gebaute Apps können Datensätze anlegen, aber nicht bearbeiten, oder erlauben jedem, alles zu löschen.

Ein Alltagsvergleich: ein Rezeptkartenkasten

Stellen Sie sich einen Kasten mit Rezeptkarten auf dem Küchenregal vor.

  • Create: Eine neue Karte schreiben und einsortieren.
  • Read: Durch den Kasten blättern oder die Karte für Lasagne herausziehen.
  • Update: „200 g Käse“ durchstreichen und „250 g“ daneben schreiben.
  • Delete: Eine Karte herausnehmen und wegwerfen.

Jetzt kommen Regeln hinzu: Nur der Küchenchef darf Karten wegwerfen, jede Karte braucht einen Titel, und niemand darf zwei Karten mit demselben Namen anlegen. Das ist eine CRUD-App mit Validierung und Berechtigungen – und genau daraus bestehen die meisten echten Apps.

Wie CRUD in jeder Schicht auftaucht

Jede Operation erscheint im Bildschirm, im Server und in der Datenbank. Nebeneinander gezeigt erklärt das viel darüber, wie Apps gebaut werden.

OperationAuf dem BildschirmAPI-Anfrage (REST)SQL in der Datenbank
CreateEin Button „Neu“ und ein FormularPOST /api/suppliersINSERT
ReadEine Liste mit Suche und Filtern; eine DetailseiteGET /api/suppliers und GET /api/suppliers/42SELECT
UpdateEin Formular „Bearbeiten“ oder Bearbeiten direkt in der ZeilePUT oder PATCH /api/suppliers/42UPDATE
DeleteEin Button „Löschen“ mit BestätigungDELETE /api/suppliers/42DELETE (oder die Zeile als gelöscht markieren)

Der Bildschirm ist das Frontend, die API-Anfrage ist die Art, wie das Frontend mit dem Backend spricht, und das SQL ist die Art, wie das Backend mit der Datenbank spricht. Wenn Ihnen diese Begriffe neu sind, lesen Sie was eine API ist und was eine Datenbank ist.

Ein praktisches Beispiel: ein Verleih-Tracker für Ausrüstung

Die Medienabteilung einer Schule verleiht Kameras und Mikrofone an Schüler und verliert ständig den Überblick. Sie wollen eine einfache App.

Die Datensätze. Zwei Arten von Dingen: Ausrüstung (Name, Typ, Seriennummer, Zustand) und Ausleihen (welches Gerät, welcher Schüler, Ausleihdatum, Fälligkeitsdatum, Rückgabedatum).

CRUD für Ausrüstung:

  • Create: Mitarbeitende legen eine neue Kamera mit ihrer Seriennummer an. Regel: Seriennummern müssen eindeutig sein.
  • Read: Eine Liste aller Geräte, filterbar nach Typ und nach „jetzt verfügbar“; eine Detailseite mit der Ausleihhistorie eines Geräts.
  • Update: Den Zustand auf „muss repariert werden“ setzen.
  • Delete: Meist kein echtes Löschen. Wird eine Kamera mit 30 früheren Ausleihen gelöscht, verlieren diese Ausleihen ihre Verknüpfung. Stattdessen wird sie als „ausgemustert“ markiert, damit sie aus der Liste der Verfügbaren verschwindet, ihre Historie aber bleibt. Das nennt man Soft Delete.

CRUD für Ausleihen:

  • Create: Ein Gerät an einen Schüler ausleihen. Regel: Ein Gerät, das bereits verliehen ist, kann nicht erneut ausgeliehen werden.
  • Read: „Überfällige Ausleihen“ – eine Liste, bei der das Fälligkeitsdatum vorbei ist und kein Rückgabedatum existiert.
  • Update: Das Rückgabedatum eintragen, wenn das Gerät zurückkommt.
  • Delete: Nur Mitarbeitende, für Ausleihen, die versehentlich falsch eingetragen wurden.

Berechtigungen. Schüler können lesen, was verfügbar ist; nur Mitarbeitende dürfen anlegen, ändern oder löschen. Diese Prüfungen laufen auf dem Server, nicht nur durch das Ausblenden von Buttons.

Das ist die ganze App. Die interessanten Teile – keine Doppelausleihe, eine Liste der Überfälligen, eine Historie pro Gerät – sind Regeln und Abfragen oben auf dem einfachen CRUD.

Wichtige Begriffe

  • Datensatz (Zeile): Ein einzelnes Element, etwa ein Lieferant oder eine Ausleihe.
  • Entität / Ressource: Eine Art von Datensatz, etwa „Lieferanten“. Jede bekommt meist eine eigene Tabelle und einen eigenen Satz CRUD-Bildschirme.
  • Validierung: Prüfungen der Eingaben – Pflichtfelder, gültige E-Mail, positive Menge. Machen Sie es im Formular der Bequemlichkeit halber und auf dem Server aus Sicherheitsgründen.
  • Soft Delete: Einen Datensatz als gelöscht oder archiviert markieren, statt ihn zu entfernen, damit Historie und Verknüpfungen erhalten bleiben.
  • Paginierung: Eine lange Liste seitenweise anzeigen, damit die App schnell bleibt.
  • Audit-Log: Eine Aufzeichnung, wer wann was angelegt, geändert oder gelöscht hat.
  • Admin-Panel: Eine Reihe von CRUD-Bildschirmen, mit denen Mitarbeitende die Daten einer App verwalten.

Häufige Fehler und Missverständnisse

  • Eine der vier Operationen vergessen. Apps werden oft mit Anlegen und Lesen, aber ohne Bearbeiten ausgeliefert, sodass jeder Tippfehler Löschen und neu Eintippen bedeutet. Prüfen Sie für jede Entität alle vier.
  • Löschungen, die Dinge kaputt machen. Einen Kunden mit Rechnungen zu löschen kann verwaiste Rechnungen hinterlassen oder die Historie auslöschen. Entscheiden Sie pro Entität: Löschen blockieren, Soft Delete oder auch die verknüpften Datensätze löschen.
  • Berechtigungen nur in der Oberfläche. Den Löschen-Button auszublenden hindert niemanden daran, die DELETE-Anfrage zu senden. Der Server muss prüfen, wer fragt.
  • Aktualisieren per ID ohne Besitzprüfung. Wenn Nutzer A /api/notes/42 bearbeiten kann, indem er eine Zahl in der URL ändert, kann er die Notiz von Nutzer B bearbeiten. Jedes Update und jedes Löschen muss bestätigen, dass der Datensatz dem Anfragenden gehört.
  • Keine Bestätigung beim Löschen. Ein einziger Fehltipp sollte keine Daten zerstören. Verlangen Sie einen Bestätigungsschritt oder eine Rückgängig-Funktion.
  • „CRUD heißt einfach, das lohnt sich nicht.“ Viele wertvolle Produkte sind CRUD-Apps, die besser zu einem Arbeitsablauf passen als ein generisches Werkzeug.

Was Sie Ihren KI-Builder bitten sollten

Nutzen Sie dieses Muster für jede Entität, eine nach der anderen:

Erstelle eine Funktion Lieferanten mit Liste, Anlegen, Bearbeiten und Löschen. Felder: Name (Pflicht), Kontakt-E-Mail (gültige E-Mail), Telefon, Kategorie (eine von: Lebensmittel, Verpackung, Reinigung), Notizen. Listenansicht mit Suche nach Name und Filter nach Kategorie, 20 pro Seite. Vor dem Löschen bestätigen; hat ein Lieferant Bestellungen, archivieren statt löschen. Nur angemeldete Mitarbeitende dürfen anlegen, bearbeiten oder archivieren – erzwinge das auf dem Server.

Testen Sie danach alle vier Operationen, einmal als berechtigter Nutzer und einmal als jemand ohne Zugriff. Wenn eine Entität funktioniert, fügen Sie die nächste hinzu. So bauen Sie ein internes Tool zeigt, wie CRUD-Bildschirme zu einer vollständigen Admin-App werden, und was Postgres ist erklärt die Datenbank, auf der die meisten dieser Apps aufsetzen.

CRUD-Apps auf Mythex

CRUD-Apps gehören zu den Dingen, die KI-App-Builder am besten können, und Mythex macht da keine Ausnahme. Beschreiben Sie im Chat die Entität und ihre Felder, und Mythex hängt dem Projekt eine Postgres-Datenbank an, legt die Tabelle an und baut die Listen-, Formular- und Detailbildschirme in einer Live-Vorschau; danach können Sie /test ausführen, um den Ablauf zu prüfen. Die Dokumentation enthält ein Rezept für CRUD-Apps mit einem Startprompt, und der Builder für interne Tools sowie die Dashboard-Vorlagen sind gute Startpunkte.

Fragen

Wofür steht CRUD?

CRUD steht für Create, Read, Update und Delete: einen neuen Datensatz anlegen, Datensätze ansehen, einen Datensatz ändern und einen entfernen. Fast jede App, die Daten speichert, besteht aus diesen vier Operationen.

Was ist eine CRUD-App?

Eine CRUD-App ist eine App, deren Hauptaufgabe die Verwaltung von Datensätzen über Formulare, Listen und Detailseiten ist, etwa ein CRM, ein Inventar-Tracker, ein Buchungs-Admin oder ein Jobboard-Backend. Die meisten internen Tools und Admin-Panels sind CRUD-Apps.

Wie hängt CRUD mit REST-APIs zusammen?

In einer typischen REST-API nutzt Create eine POST-Anfrage, Read eine GET-Anfrage, Update PUT oder PATCH, und Delete DELETE. Das Backend führt dann die passende Datenbankoperation aus: INSERT, SELECT, UPDATE oder DELETE.

Ist eine CRUD-App zu einfach, um wertvoll zu sein?

Nein. Viel nützliche Geschäftssoftware ist CRUD mit guten Regeln, Berechtigungen und Auswertungen obendrauf. Der Wert liegt darin, die Daten gut zu modellieren und zum Arbeitsablauf zu passen, nicht in ungewöhnlicher Technik.

Mythex · Pricing · Alles mit KI bauen · Vorlagen für Websites und Apps · Mythex im Vergleich · Glossar zum App-Bau mit KI · Kostenlose Tools für den App-Bau mit KI · English

English አማርኛ العربية Български বাংলা Bosanski Català Čeština Dansk Ελληνικά Español Español (España) Eesti فارسی Suomi Français Français (Canada) ગુજરાતી हिन्दी Hrvatski Magyar Հայերեն Bahasa Indonesia Íslenska Italiano 日本語 ქართული Қазақ тілі ಕನ್ನಡ 한국어 Lietuvių Latviešu Македонски മലയാളം Монгол मराठी Bahasa Melayu မြန်မာ Norsk bokmål Nederlands ਪੰਜਾਬੀ Polski Português (Brasil) Português (Portugal) Română Русский Slovenčina Slovenščina Soomaali Shqip Srpski Svenska Kiswahili தமிழ் తెలుగు ไทย Tagalog Türkçe Українська اردو Tiếng Việt 简体中文 繁體中文(香港) 繁體中文(台灣)