EMZETT.CRUD
Kurz: Die vier Grundoperationen der Datenverarbeitung: Create, Read, Update, Delete.
Genauer: Nahezu jede Anwendung mit Datenhaltung bildet diese vier Operationen irgendwo ab — sei es als Datenbank-Befehle (INSERT, SELECT, UPDATE, DELETE in SQL) oder als REST-Endpunkte (POST, GET, PUT/PATCH, DELETE). Dient als gemeinsames Vokabular, um über die Grundfunktionalität eines Systems zu sprechen.
Im Detail
Die vier CRUD-Operationen bilden sich in nahezu jeder Schicht einer Anwendung auf ähnliche Weise ab, nur mit unterschiedlichem Vokabular:
| CRUD | SQL | REST/HTTP |
|---|---|---|
| Create | INSERT | POST |
| Read | SELECT | GET |
| Update | UPDATE | PUT/PATCH |
| Delete | DELETE | DELETE |
PUT ersetzt bei REST typischerweise eine ganze Ressource, PATCH ändert nur einzelne Felder — dieser Unterschied wird in der Praxis nicht immer sauber eingehalten. Ein “CRUD-Interface” oder “CRUD-Screen” ist in der Anwendungsentwicklung ein gängiger Begriff für eine einfache Verwaltungsoberfläche, die im Wesentlichen nur diese vier Operationen auf einer Datenbanktabelle anbietet — viele Admin-Panels (z. B. das von Django automatisch generierte) sind im Kern nichts anderes.
In der Praxis kommt bei sensiblen Daten oft eine Variante dazu: statt eines echten Delete wird nur ein Flag gesetzt (“Soft Delete”), damit Daten aus Nachvollziehbarkeits- oder Rechtsgründen (z. B. DSGVO) nicht sofort unwiderruflich verschwinden.
CRUD als Startpunkt, nicht Endpunkt
CRUD-Operationen decken zwar die Grundfunktionalität ab, reale Anwendungen brauchen aber fast immer zusätzliche, fachlich spezifischere Operationen, die sich nicht sauber in dieses Schema pressen lassen — z. B. “Bestellung stornieren” (mehr als ein simples Update, löst oft weitere Prozesse wie Rückerstattung aus) oder “Passwort zurücksetzen” (kein Create/Update im klassischen Sinn, sondern ein eigener, mehrstufiger Ablauf). Ein rein CRUD-basiertes API-Design (“CRUDy API”) gilt deshalb manchmal als Warnzeichen für ein zu simples Domänenmodell, das die eigentliche Geschäftslogik nicht abbildet, sondern nur den Datenbankzugriff durchreicht.
Idempotenz
Ein wichtiges technisches Detail: PUT und DELETE sollten laut HTTP-Spezifikation idempotent sein — ein wiederholter identischer Aufruf soll denselben Endzustand erzeugen wie ein einzelner Aufruf (z. B. “lösche Ressource X” zweimal hintereinander führt zum selben Ergebnis wie einmal). POST (Create) ist dagegen bewusst NICHT idempotent — zwei identische POST-Anfragen erzeugen typischerweise zwei neue Ressourcen, was bei Netzwerkfehlern und automatischen Wiederholungsversuchen (“Retries”) zu ungewollten Duplikaten führen kann, wenn man diesen Unterschied nicht beachtet.