CRUD ist ein Kürzel für Create, Read, Update und Delete – die vier Grundoperationen, die jeder persistente Datenspeicher unterstützen muss. Geprägt in James Martins Managing the Data-base Environment von 1983, ist es bis heute das langlebigste Akronym der Backend-Arbeit, weil es das Fundament benennt: Was Ihr System sonst auch tut – Datensätze müssen entstehen, gefunden werden, sich ändern und wieder verschwinden.
Das Wichtigste in Kürze
| Frage | Antwort |
|---|---|
| Die vier Verben | Create · Read · Update · Delete – das Minimum der Persistenz |
| In SQL | INSERT · SELECT · UPDATE · DELETE |
| Über HTTP | POST · GET · PUT/PATCH · DELETE |
| vs. REST | CRUD ist, was Sie mit Daten tun; REST ist, wie Clients Ressourcen erreichen |
| Der moderne Ansatz | Die CRUD-Schicht wird generiert, nicht geschrieben |
CRUD in vier Sprachen
-- CRUD in SQL: die ursprüngliche Zuordnung
INSERT INTO tasks (title) VALUES ('Write the launch post'); -- C
SELECT * FROM tasks WHERE done = false; -- R
UPDATE tasks SET done = true WHERE id = 42; -- U
DELETE FROM tasks WHERE id = 42; -- D
Und derselbe Zyklus, wie ihn ein SDK ausdrückt – die Form, in der der meiste Anwendungscode tatsächlich geschrieben wird:
// JavaScript / Node.js — Back4app JS SDK
// The full CRUD cycle on one object
const task = new Parse.Object('Task');
task.set('title', 'Write the launch post'); // C — create
await task.save();
const fetched = await new Parse.Query('Task')
.equalTo('done', false).first(); // R — read
fetched.set('done', true); // U — update
await fetched.save();
await fetched.destroy(); // D — delete // Flutter / Dart — Back4app Flutter SDK
// The full CRUD cycle on one object
final task = ParseObject('Task')..set('title', 'Write the launch post');
await task.save(); // C — create
final query = QueryBuilder<ParseObject>(ParseObject('Task'))
..whereEqualTo('done', false);
final fetched = (await query.query()).results!.first; // R — read
fetched.set('done', true);
await fetched.save(); // U — update
await fetched.delete(); // D — delete // iOS / Swift — Back4app Swift SDK
// The full CRUD cycle on one object
var task = Task()
task.title = "Write the launch post"
let saved = try await task.save() // C — create
let fetched = try await Task.query("done" == false)
.first() // R — read
var updated = fetched
updated.done = true
_ = try await updated.save() // U — update
try await updated.delete() // D — delete // Android / Kotlin — Back4app Android SDK
// The full CRUD cycle on one object
val task = ParseObject("Task").apply {
put("title", "Write the launch post")
}
task.save() // C — create
val fetched = ParseQuery.getQuery<ParseObject>("Task")
.whereEqualTo("done", false).first // R — read
fetched.put("done", true)
fetched.save() // U — update
fetched.delete() // D — delete Eine Tabelle für alle Zuordnungen
Die Zuordnung über sechs Spalten, die keine einzelne Referenz zusammenstellt:
| Operation | SQL | HTTP-Verb | Status | Dokumentdatenbank | SDK-/ORM-Idiom |
|---|---|---|---|---|---|
| Create | INSERT | POST | 201 | insertOne | object.save() (neu) |
| Read | SELECT | GET | 200 | find / findOne | query.find() / .get() |
| Update | UPDATE | PUT / PATCH | 200 | updateOne | object.save() (geänderte Felder) |
| Delete | DELETE | DELETE | 204 | deleteOne | object.destroy() |
Zwei Fußnoten aus der HTTP-Spezifikation, die man wirklich kennen sollte: GET ist sicher (keine Zustandsänderung), PUT und DELETE sind idempotent (ohne Schaden wiederholbar), POST ist keines von beiden – deshalb behandelt Retry-Logik sie unterschiedlich, und deshalb bedeutet PUT “vollständig ersetzen”, PATCH dagegen “teilweise ändern”.
Wo CRUD stattfindet
Das Diagramm ist zugleich eine Sicherheitsmahnung: Jedes Verb passiert die API-Schicht, und genau dort gehören Berechtigungen und Validierung hin – eine CRUD-Schnittstelle ohne Zugriffskontrolle pro Operation ist nichts anderes als eine öffentliche Datenbank mit Umweg.
CRUD vs. REST
| Frage | CRUD | REST |
|---|---|---|
| Was es benennt | Operationen auf Daten | Einen Architekturstil für Clients und Ressourcen |
| Definiert durch | Vier Verben | Constraints: zustandslos, einheitliche Schnittstelle, cachebar… |
| Wo es lebt | SQL, SDKs, Queues, überall | HTTP-APIs |
| Beziehung | Der übliche Inhalt von REST-Endpoints | Oft auf CRUD abgebildet – kann aber auch Aktionen jenseits von CRUD bereitstellen |
Die praktische Erkenntnis: Eine REST-API ist häufig eine CRUD-API im HTTP-Gewand – aber “Rechnung freigeben” gehört in Ihre API und ist kein CRUD-Verb, und CRUD existiert problemlos ganz ohne HTTP. Die Begriffe ergänzen sich; sie konkurrieren nicht.
Typische Anwendungsfälle
- Die klassische CRUD-App. Admin-Panels, CMS, CRM, Lagerverwaltung, Buchungen – der Großteil der Unternehmenssoftware, und das ganz ehrenwert.
- Prototypen und MVPs. Die vier Verben auf einer Handvoll Klassen sind die erste Version der meisten Produkte.
- Automatisch generierte APIs. Schema rein, CRUD-Schnittstelle raus – der moderne Standard, der die vier Verben zu Konfiguration statt Code macht; ausführlich behandelt im Eintrag zu automatisch generierten APIs.
- Admin- und Support-Werkzeuge. Visuelle Tabellenansichten über derselben CRUD-Schnittstelle, Berechtigungen inklusive.
- Das Fundament unter allem anderen. Auch Systeme mit Event Sourcing oder vielen Workflows stellen irgendwo CRUD bereit – Einstellungen, Profile, Stammdaten.
Sollte jede Aktion CRUD sein? Eine Entscheidungsmatrix
| Modellieren Sie es als CRUD, wenn… | Greifen Sie zu mehr, wenn… |
|---|---|
| Der aktuelle Zustand des Datensatzes die Wahrheit ist | Die Historie die Domäne ist → Event Sourcing |
| Bearbeiten dem Denkmodell der Nutzer entspricht | Lesen und Schreiben unterschiedlich skalieren → CQRS |
| ”Löschen” wirklich entfernen darf | Audit oder Rückgängigmachen Soft Deletes verlangen |
| Gleichzeitige Änderungen selten sind | Verlorene Updates drohen → optimistisches Sperren, Versionen |
| Die Aktion “diesen Datensatz ändern” lautet | Die Aktion ein Geschäftsverb ist → benennen Sie den Workflow |
Die letzte Zeile ist das Designwarnsignal, das man sich merken sollte: Wenn Endpoint-Namen in Richtung updateStatus abdriften, verlangt die Domäne nach eigenen Verben.
Grenzen und Trade-offs
- Update zerstört Historie. Die Änderung an Ort und Stelle ist der prägende Akt von CRUD und zugleich sein prägender Verlust – alles, was wissen muss, “wie das am Dienstag aussah”, braucht ein Journal oder Events.
- Löschen ist eine Richtlinie, kein Verb. Soft vs. Hard Delete wägt Nachvollziehbarkeit gegen datenschutzrechtliche Löschpflichten und Abfragekomplexität ab; entscheiden Sie pro Klasse, und zwar bewusst.
- Nebenläufigkeit ist nicht eingepreist. Zwei Updates, der letzte Schreiber gewinnt, die Änderung des ersten ist stillschweigend weg – Versionsfelder und bedingtes Speichern sind das übliche Gegenmittel.
- List ist das fünfte Verb. Filtern, Sortieren und Paginierung tragen den Großteil des realen Lesetraffics und die meisten Performance-Bugs – der Grund, warum es CRUDL und BREAD gibt.
- CRUD-APIs können blutleer werden. Eine Schnittstelle, die nur Zeilen hinein- und herausreicht, drängt Geschäftslogik in die Clients; halten Sie die Workflows auf dem Server, direkt bei den Daten.
CRUD mit Back4app
Back4app ist eine Open-Source-Plattform für Backend as a Service (BaaS), die eine verwaltete Datenbank, automatisch generierte REST- und GraphQL-APIs, Authentifizierung, Dateispeicher und Serverless-Funktionen mit Cloud Code kombiniert. Ihr Beitrag zu diesem Artikel ist Subtraktion: Sie definieren eine Klasse, und die gesamte CRUD-Matrix von oben existiert auf einen Schlag – REST-Endpoints gemäß der HTTP-Spalte, GraphQL-Mutations und die SDK-Idiome aus den Code-Tabs, wobei Berechtigungen auf Klassenebene jedes Verb absichern und beforeSave-Trigger die Validierung übernehmen. Die vier Verben sind nicht länger Ihre Codebasis, sondern Ihr Vokabular.
Häufige Fragen
Wofür steht CRUD?
Für Create, Read, Update, Delete – also Anlegen, Lesen, Aktualisieren, Löschen: die vier grundlegenden Operationen persistenter Speicherung und das Minimum, das jede datengestützte Anwendung beherrschen muss. Bekannt gemacht hat das Akronym James Martin in seinem Buch Managing the Data-base Environment von 1983; verwandte Semantik formalisierte Haim Kilov 1990. Damit ist es einer der ältesten Begriffe im Backend-Vokabular, die noch täglich verwendet werden.
Wie lässt sich CRUD auf SQL und HTTP abbilden?
Zwei saubere Zuordnungen, die sich jeder Entwickler einmal einprägt: In SQL ist Create INSERT, Read SELECT, Update UPDATE und Delete DELETE. Über HTTP ist Create POST, Read GET, Update PUT für den vollständigen Ersatz oder PATCH für Teiländerungen und Delete DELETE – mit 201, 200 und 204 als jeweiligen Statuscodes im Erfolgsfall.
Ist CRUD dasselbe wie REST?
Nein – beide beantworten unterschiedliche Fragen. CRUD benennt, was Sie mit Daten tun; REST ist ein Architekturstil dafür, wie Clients über HTTP mit Ressourcen interagieren, mit Constraints wie Zustandslosigkeit und einer einheitlichen Schnittstelle. REST-Endpoints lassen sich oft sauber auf CRUD abbilden, doch REST kann auch Aktionen jenseits von CRUD bereitstellen, und CRUD existiert problemlos außerhalb von HTTP – in SQL-Sessions, SDKs und Queues.
Was ist der Unterschied zwischen PUT und PATCH?
Der Umfang der Änderung. PUT ersetzt die gesamte Ressource durch die gesendete Repräsentation – per Definition idempotent, denn zweimaliges Senden ergibt denselben Zustand. PATCH wendet eine Teiländerung an – nur die gesendeten Felder ändern sich. Der Großteil realer Update-Anfragen hat die Form eines PATCH, weshalb die save()-Methoden der SDKs nur geänderte Felder senden.
Was ist eine CRUD-App?
Eine Anwendung, deren Kernablauf darin besteht, Datensätze anzulegen, anzuzeigen, zu bearbeiten und zu löschen – Admin-Panels, CMS, CRM, Lager- und Buchungssysteme. Der Begriff klingt leicht abschätzig, was er nicht sollte: Der Großteil der Unternehmenssoftware ist im Kern CRUD – und genau deshalb nehmen Plattformen, die die CRUD-Schicht automatisch generieren, so viel Arbeit ab.
Was ist ein Soft Delete?
Einen Datensatz als gelöscht zu markieren – mit einem Flag oder Zeitstempel –, statt ihn zu entfernen. Das bewahrt Audit-Historie, referenzielle Integrität und die Möglichkeit zum Rückgängigmachen, um den Preis, dass jede Abfrage filtern muss und Unique-Constraints komplizierter werden. Das Gegenstück, der Hard Delete, entfernt tatsächlich – und Datenschutzregeln wie Löschanfragen nach der DSGVO können genau das verlangen. Die meisten Systeme brauchen eine bewusste Richtlinie pro Klasse statt eines Standards.
Wann reicht CRUD nicht aus?
Wenn es in der Domäne um Ereignisse und Historie statt um den aktuellen Zustand geht. Ein Update an Ort und Stelle zerstört die Vergangenheit – Event Sourcing führt ein Append-only-Log und leitet den Zustand daraus ab; CQRS trennt Lese- und Schreibmodell vollständig. Und Geschäftsaktionen wie "Rechnung freigeben" oder "Bestellung abschließen" sind Workflows, keine Zeilenänderungen – wer sie als bloße Updates modelliert, verschleiert die Domäne. CRUD ist der Boden des Datenzugriffs, nicht die Decke.
Was sind CRUD-Varianten wie CRUDL und BREAD?
Erweiterungen und Umschreibungen derselben Idee: CRUDL ergänzt List als eigene Operation neben dem Lesen eines einzelnen Datensatzes; BREAD buchstabiert es als Browse, Read, Edit, Add, Delete. Beide tragen der praktischen Wahrheit Rechnung, dass das Auflisten von Collections – mit Filterung und Paginierung – eine eigene Operation mit eigenen Designentscheidungen ist und nicht bloß "Lesen im Plural".