CRUD
Daten entstehen, werden abgerufen, verändert und irgendwann entfernt. Jede Anwendung, die Informationen speichert, setzt genau diese vier Schritte um. Das Akronym dafür lautet CRUD: Create, Read, Update, Delete.
CRUD definiert die vier fundamentalen Operationen, die auf persistente Datensätze angewendet werden. Egal ob relationale Datenbanken, dokumentenbasierte Speicher, Dateisysteme oder verteilte Cloud-Dienste: Die Grundstruktur bleibt identisch. Create legt einen neuen Datensatz an. Read gibt einen bestehenden Datensatz zurück. Update verändert einen bestehenden Datensatz. Delete entfernt ihn.
Der Begriff stammt aus der Datenbanktheorie und geht auf James Martin zurück, der ihn 1983 in "Managing the Data-base Environment" prägte. Seitdem hat sich CRUD als Standardvokabular in der Softwareentwicklung etabliert, weil es eine technologieübergreifende Beschreibungsebene bietet.
Die vier Operationen im Detail
Create erzeugt einen neuen Eintrag im Zielsystem. In SQL entspricht das einem INSERT-Statement, in einer REST-Schnittstelle einem POST-Request. Die Operation erwartet Eingabedaten, validiert sie gegen das Datenmodell und schreibt den neuen Datensatz in den Speicher.
Beispiel: Ein Nutzer registriert sich auf einer Plattform. Die Anwendung nimmt E-Mail-Adresse, Name und Passwort-Hash entgegen, prüft auf Duplikate und legt den Datensatz in der Nutzertabelle an. Der neue Eintrag erhält eine eindeutige ID.
Read ruft bestehende Daten ab, ohne sie zu verändern. In SQL ist das SELECT, in REST ein GET-Request. Read-Operationen können einzelne Datensätze oder gefilterte Listen zurückgeben.
Beispiel: Ein Dashboard zeigt alle offenen Support-Tickets sortiert nach Erstellungsdatum. Die Read-Operation filtert nach Status "offen" und sortiert absteigend.
Update verändert einen bestehenden Datensatz. SQL nutzt UPDATE, REST bietet PUT (vollständiges Ersetzen) und PATCH (partielles Aktualisieren). Die Unterscheidung zwischen PUT und PATCH ist semantisch relevant: PUT ersetzt den gesamten Datensatz, PATCH ändert nur die übermittelten Felder.
Beispiel: Ein Nutzer ändert seine E-Mail-Adresse im Profil. Ein PATCH-Request sendet nur das Feld "email" mit dem neuen Wert. Der Server aktualisiert dieses eine Feld, ohne andere Profildaten zu berühren.
Delete entfernt einen Datensatz. SQL verwendet DELETE, REST den gleichnamigen HTTP-Verb. In der Praxis unterscheidet man zwischen Hard Delete (physisches Löschen) und Soft Delete (Markierung als gelöscht, Daten bleiben erhalten).
Beispiel: Ein Content-Management-System verschiebt einen Artikel in den Papierkorb. Technisch setzt ein Soft Delete das Feld "deleted_at" auf den aktuellen Zeitstempel. Der Datensatz bleibt in der Datenbank, wird aber aus allen Abfragen ausgeschlossen, die nur aktive Einträge laden.
Zuordnung zu Protokollen und Sprachen
CRUD bildet eine Abstraktionsschicht, die sich auf verschiedene technische Implementierungen abbilden lässt. Die folgende Zuordnung zeigt die gängigsten Entsprechungen:
Beispiel: Eine mobile App speichert Nutzerdaten über eine REST-Schnittstelle. Der POST-Endpunkt /users erzeugt ein neues Konto (Create). GET /users/42 ruft ein Profil ab (Read). PATCH /users/42 aktualisiert einzelne Felder (Update). DELETE /users/42 deaktiviert das Konto (Delete).
CRUD in der Schnittstellengestaltung
REST-Architekturen bilden CRUD direkt auf HTTP-Methoden ab. Diese Zuordnung ist so stark verankert, dass viele Frameworks automatisch Routen für alle vier Operationen generieren, sobald eine Ressource definiert wird. Ruby on Rails, Django, Laravel und Spring Boot folgen diesem Muster.
Beispiel: Ein Framework generiert aus der Ressourcendefinition "Artikel" automatisch die Endpunkte POST /artikel, GET /artikel, GET /artikel/:id, PUT /artikel/:id, PATCH /artikel/:id und DELETE /artikel/:id. Jeder Endpunkt ist einer CRUD-Operation zugeordnet.
Die strenge CRUD-Zuordnung hat Grenzen. Nicht jede fachliche Operation passt sauber in eine der vier Kategorien. Ein Archivierungsvorgang ist kein klassisches Delete und kein Update. Ein Massenimport ist mehr als ein einzelnes Create. In solchen Fällen entstehen sogenannte Custom Actions, die über CRUD hinausgehen.
Beispiel: Ein Rechnungssystem braucht die Operation "Rechnung stornieren". Das ist weder ein Delete (die Rechnung muss erhalten bleiben) noch ein einfaches Update (es entsteht ein neuer Stornodatensatz). Die Lösung: POST /rechnungen/42/stornierung als Custom Action außerhalb des reinen CRUD-Musters.
GraphQL behandelt CRUD anders als REST. Statt der Zuordnung zu HTTP-Methoden unterscheidet GraphQL nur zwischen Queries (Read) und Mutations (Create, Update, Delete). Die Benennung der Mutationen folgt eigenen Konventionen wie createUser, updateUser, deleteUser.
CRUD auf Datenbankebene
Auf Datenbankebene bildet CRUD die Grundlage jeder Interaktion mit persistenten Daten. Relationale Datenbanken setzen die vier Operationen über SQL-Statements um: INSERT INTO erzeugt Zeilen, SELECT liest sie, UPDATE ändert Werte und DELETE entfernt Zeilen.
Beispiel: Eine Produktdatenbank führt pro Tag tausende CRUD-Operationen aus. Neue Artikel werden per INSERT angelegt, Preise per UPDATE angepasst, Katalogansichten per SELECT generiert und auslaufende Produkte per DELETE oder Soft-Delete archiviert.
Dokumentenbasierte Datenbanken wie MongoDB verwenden stattdessen Methoden wie insertOne(), find(), updateOne() und deleteOne(). Die Benennung weicht ab, die Semantik bleibt identisch.
Transaktionssicherheit spielt bei CRUD eine zentrale Rolle. Ohne Transaktionen können gleichzeitige Schreibzugriffe zu inkonsistenten Zuständen führen. Relationale Datenbanken bieten ACID-Garantien (Atomicity, Consistency, Isolation, Durability), die sicherstellen, dass eine CRUD-Operation entweder vollständig durchgeführt oder vollständig zurückgerollt wird.
Beispiel: Ein Buchungssystem transferiert 100 Euro von Konto A nach Konto B. Das erfordert zwei UPDATE-Operationen innerhalb einer Transaktion. Schlägt die zweite fehl, wird auch die erste rückgängig gemacht. Ohne Transaktion wäre das Geld von Konto A verschwunden, aber nie auf Konto B angekommen.
CRUD in KI-Systemen
KI-Systeme nutzen CRUD-Operationen an mehreren Stellen. Die Verwaltung von Trainingsdaten basiert auf denselben vier Grundoperationen: Datensätze werden angelegt, abgerufen, korrigiert und bei Qualitätsmängeln entfernt.
Beispiel: Ein Team bereitet einen Datensatz für das Fine-Tuning eines Sprachmodells vor. Create fügt neue Trainingspaare (Eingabe und erwartete Ausgabe) hinzu. Read prüft bestehende Paare auf Plausibilität. Update korrigiert fehlerhafte Labels. Delete entfernt doppelte oder widersprüchliche Einträge.
RAG-Systeme (Retrieval-Augmented Generation) zeigen, wie CRUD über klassische Datenbanken hinaus wirkt. Die Wissensbasis eines RAG-Systems ist ein Vektorspeicher, der mit Embeddings arbeitet. Auch hier gelten die vier Operationen: Dokumente werden indexiert (Create), bei Anfragen durchsucht (Read), bei Änderungen neu berechnet (Update) und bei Bedarf aus dem Index entfernt (Delete).
Beispiel: Ein Unternehmen betreibt einen Chatbot mit RAG-Anbindung an die interne Wissensbasis. Wenn eine Betriebsvereinbarung geändert wird, muss der alte Eintrag im Vektorspeicher aktualisiert werden (Update). Ohne diesen Schritt liefert der Chatbot veraltete Antworten.
Prompt-Bibliotheken folgen ebenfalls dem CRUD-Muster. Neue Prompts werden erstellt und gespeichert, bestehende abgerufen und getestet, wirksame Varianten aktualisiert und unwirksame entfernt.
Entwurfsmuster rund um CRUD
Über die vier Grundoperationen hinaus haben sich Muster entwickelt, die CRUD erweitern oder alternative Perspektiven bieten.
Active Record und Repository
Das Active-Record-Muster bindet CRUD direkt an das Datenobjekt. Jedes Objekt kennt Methoden wie save(), find(), update() und destroy(). Das Repository-Muster trennt dagegen Datenzugriff und Geschäftslogik. Statt user.save() ruft der Code userRepository.save(user) auf.
Beispiel: Ein E-Commerce-System verwaltet Bestellungen. Im Active-Record-Ansatz ruft der Controller direkt order.save() auf. Im Repository-Ansatz delegiert der Controller an orderRepository.save(order). Der zweite Ansatz erleichtert das Testen, weil das Repository durch ein Mock-Objekt ersetzt werden kann.
CQRS: Lesen und Schreiben trennen
Command Query Responsibility Segregation trennt Read-Operationen von Create-, Update- und Delete-Operationen. Statt einer einzigen Schnittstelle für alle CRUD-Operationen gibt es zwei getrennte Modelle: ein Lesemodell (optimiert für Abfragen) und ein Schreibmodell (optimiert für Konsistenz).
Beispiel: Ein Produktkatalog mit Millionen Artikeln nutzt für Suchanfragen (Read) einen Suchindex, der auf schnelle Abfragen optimiert ist. Schreiboperationen (Create, Update, Delete) gehen an die relationale Datenbank, die Konsistenz garantiert. Ein Synchronisationsprozess hält beide Systeme aktuell.
Event Sourcing
Event Sourcing speichert nicht den aktuellen Zustand eines Datensatzes, sondern die gesamte Historie aller Änderungen. Statt einer Update-Operation wird ein Änderungsereignis protokolliert. Der aktuelle Zustand ergibt sich aus der Abfolge aller Ereignisse.
Beispiel: Ein Kontosystem speichert nicht den aktuellen Kontostand, sondern jede einzelne Transaktion: "Einzahlung 500 Euro", "Abbuchung 50 Euro", "Zinsgutschrift 2,50 Euro". Der aktuelle Stand wird aus der Summe aller Ereignisse berechnet. Das ermöglicht vollständige Nachvollziehbarkeit und die Wiederherstellung früherer Zustände.
Fachliche Einordnung: CQRS und Event Sourcing stellen keine Alternative zu CRUD dar, sondern bauen darauf auf. Auch in Event-Sourcing-Systemen existieren die vier Grundoperationen. Die Änderung liegt in der Art der Speicherung, nicht in der Abkehr vom CRUD-Prinzip.Grenzen und typische Fehlerquellen
CRUD beschreibt die Mechanik der Datenverwaltung, nicht die fachliche Logik dahinter. Die häufigste Fehlerquelle bei CRUD-basierten Systemen ist die Verwechslung von technischer Vollständigkeit mit fachlicher Korrektheit.
Beispiel: Ein System erlaubt das Löschen von Kundenkonten (Delete). Fachlich darf ein Kundenkonto mit offenen Rechnungen aber nicht gelöscht werden. Ohne diese Geschäftsregel im Code führt die Delete-Operation zu inkonsistenten Daten.
Weitere typische Probleme:
Fehlende Validierung bei Create und Update führt zu ungültigen Daten im System. Wenn ein Formular den Nachnamen als Pflichtfeld definiert, die Schnittstelle dieses Feld aber nicht prüft, können leere Nachnamen in die Datenbank gelangen.
Ungeschützte Delete-Operationen ohne Bestätigung oder Rückgabemöglichkeit verursachen Datenverlust. Soft Delete (Markierung statt physisches Löschen) reduziert dieses Risiko, erhöht aber die Komplexität bei Read-Operationen, die gelöschte Einträge ausfiltern müssen.
Race Conditions bei gleichzeitigen Update-Operationen können dazu führen, dass ein älterer Schreibvorgang einen neueren überschreibt. Optimistic Locking (Versionsnummern) oder Pessimistic Locking (Datensatzsperre) sind gängige Gegenmaßnahmen.
Beispiel: Zwei Redakteure bearbeiten gleichzeitig denselben Artikel. Ohne Locking speichert der zweite Redakteur seine Version und überschreibt die Änderungen des ersten. Mit Optimistic Locking erhält der zweite Redakteur eine Fehlermeldung, weil sich die Versionsnummer inzwischen geändert hat.
Fachliche Einordnung: CRUD ist ein Ordnungsrahmen, kein Architekturmuster. Es beschreibt, was mit Daten getan werden kann, nicht wie es implementiert werden soll. Die Implementierung erfordert immer zusätzliche Entscheidungen zu Validierung, Autorisierung, Transaktionsgrenzen und Fehlerbehandlung.