Datensätze archivieren oder löschen: Was sollte eine kleine Web-App erlauben?

Für viele kleine Web-Apps ist es sinnvoll, Archivieren und Löschen als zwei verschiedene Handlungen zu beschreiben. Archivieren blendet einen Datensatz aus dem Alltag aus und soll sich in der App rückgängig machen lassen. Löschen entfernt ihn aus der App. Ob nach dem Löschen eine Wiederherstellung möglich ist, etwa aus einer Datensicherung, ist eine eigene Zusage mit Grenzen. Legen Sie vor Projektstart fest, wer was darf und was mit verknüpften Datensätzen passiert. Dieser Artikel nennt keine Aufbewahrungsfristen.

Die Entscheidung hier betrifft den Lebenszyklus von Datensätzen im Geschäftsalltag: Wann verschwindet ein Kunde, ein Auftrag oder ein Produkt aus der Ansicht, und wann ist er wirklich weg? Welche Daten Sie aus rechtlichen Gründen wie lange aufbewahren oder löschen müssen, klären Sie bitte mit einer fachkundigen Stelle. Dieser Artikel nennt dazu keine Fristen.

Aktiv, archiviert, gelöscht: drei mögliche Zustände

Aktiv

Der Datensatz erscheint in Listen, Suchen und Auswahlfeldern und lässt sich bearbeiten.

Archiviert

Der Datensatz ist noch vorhanden, erscheint aber nicht mehr in Standardlisten und nicht in Auswahlfeldern für neue Vorgänge. Er bleibt lesbar, etwa über einen Filter Archiv. Empfehlung: Legen Sie fest, ob archivierte Datensätze noch bearbeitet werden dürfen. Im Zweifel sollten sie schreibgeschützt sein, bis jemand sie wiederherstellt.

Endgültig gelöscht

Der Datensatz ist aus der App entfernt. Empfehlung: Legen Sie ausdrücklich fest, ob es nach dem Löschen eine Wiederherstellung gibt, etwa aus einer Datensicherung, und wer sie durchführt. Gehen Sie nicht davon aus, dass sich Gelöschtes zurückholen lässt, solange das nicht schriftlich zugesagt ist. Umgekehrt ist das Löschen in der App kein Beleg dafür, dass der Datensatz auch aus allen Datensicherungen und Protokollen verschwunden ist. Auch das sollte beschrieben werden.

Verknüpfte Datensätze

Die schwierigste Frage ist nicht das Löschen eines einzelnen Datensatzes, sondern was mit allem passiert, das daran hängt. Ein Kunde hat Aufträge, ein Produkt steckt in Bestellungen. Die PostgreSQL Dokumentation beschreibt das am Beispiel von Produkten und Bestellungen: Wenn jemand ein Produkt entfernen will, das noch von einer Bestellung referenziert wird, gibt es einige Optionen, etwa das Löschen des referenzierten Produkts zu verbieten oder die Bestellungen ebenfalls zu löschen. Dieselbe Seite erklärt, dass die passende Wahl davon abhängt, was die Tabellen darstellen. Wenn die verweisende Tabelle etwas darstellt, das Bestandteil des referenzierten Objekts ist und nicht unabhängig existieren kann, kann CASCADE passend sein. Bei unabhängigen Objekten sind RESTRICT oder NO ACTION geeigneter. Das Beispiel dort: Bestellpositionen gehören zu einer Bestellung, Produkte und Bestellungen sind verschiedene Dinge.

Für Ihr Briefing übersetzt: Entscheiden Sie pro Beziehung in Alltagssprache.

• Teil eines anderen Datensatzes (etwa Positionen einer Bestellung): darf mit dem übergeordneten Datensatz verschwinden.
• Eigenständiger Datensatz (etwa Kunde und Auftrag): Löschen nur nach ausdrücklicher Entscheidung, sonst blockieren oder archivieren.
• Optionale Verknüpfung (etwa zuständige Mitarbeiterin): Verweis darf leer werden.

Das sind Empfehlungen zur Orientierung. Ob ein Datenbankmechanismus oder die Anwendungslogik die Regel durchsetzt, entscheidet Ihr Entwicklungsteam. Wichtig ist, dass die Regel existiert und getestet wird. Ob in Ihrem Fall archivieren, blockieren oder mitlöschen richtig ist, hängt von Ihrem Geschäft ab.

Wer darf archivieren, wiederherstellen, löschen?

Empfehlung für ein kleines Team, als Ausgangspunkt:

• Archivieren: alle, die den Datensatz bearbeiten dürfen, weil es umkehrbar ist.
• Wiederherstellen: dieselbe Gruppe oder eine verantwortliche Person, wenn Verwechslungen drohen.
• Endgültig löschen: nur eine kleine Gruppe, mit zusätzlicher Bestätigung, die den Namen des Datensatzes und die Zahl betroffener verknüpfter Datensätze nennt.

Die Rollenkonfiguration im Ganzen ist ein eigenes Thema. Hier geht es nur um diese drei Handlungen.

Löschen per Schnittstelle: idempotent heißt nicht gleich wiederherstellbar

Wenn Ihre App oder ein angebundenes System Datensätze über eine Web-Schnittstelle löscht, hilft ein Blick auf die Semantik. Laut MDN bittet die HTTP Methode DELETE den Server, eine bestimmte Ressource zu löschen, und in der Übersicht steht bei Idempotent der Wert Yes. Idempotent bedeutet jedoch nicht, dass jede Wiederholung dieselbe Antwort liefert, und es sagt nichts darüber, ob sich etwas zurückholen lässt. Es beschreibt die Semantik der Methode, nicht, ob Daten physisch gelöscht wurden. Die Seite nennt mehrere mögliche Erfolgsantworten: Ein 204 No Content bedeutet, die Anfrage war erfolgreich und es müssen keine weiteren Informationen zurückgesendet werden. Ein 200 OK bedeutet, dass der Antwortkörper das Ergebnis beschreibt. Ein 202 Accepted bedeutet, dass die Anfrage angenommen wurde und wahrscheinlich erfolgreich sein wird, die Ressource aber vom Server noch nicht gelöscht wurde.

Für Sie heißt das: Lassen Sie im Briefing festhalten, was die Oberfläche bei einem zweiten Löschversuch oder bei einer angenommenen, aber noch nicht ausgeführten Löschung anzeigt. Und halten Sie Wiederherstellung getrennt fest, denn die Protokollsemantik verspricht sie nicht.

Ein hypothetisches Beispiel

Stellen Sie sich einen kleinen Gartenbaubetrieb mit einer App für Kunden, Aufträge und Leistungen vor. Ein Kunde, der seit Jahren nicht mehr beauftragt hat, wird archiviert. Er verschwindet aus der Auswahl für neue Aufträge, seine alten Aufträge bleiben lesbar. Eine Mitarbeiterin legt einen Leistungseintrag doppelt an und löscht den Zweiten. Weil er nirgends verwendet wird, geht das nach einer Bestätigung. Ein Eintrag, der in alten Aufträgen vorkommt, lässt sich nicht löschen, sondern nur archivieren, und die App erklärt warum. Wiederherstellen aus dem Archiv dürfen die Büroleitung und die Inhaberin. Das Beispiel ist erfunden und beschreibt Entscheidungen, keine Ergebnisse eines realen Projekts.

Vorgeschlagene Abnahmetests

Formulieren Sie Tests als Szenarien mit Testdaten, nicht mit echten Kundendaten:

1. Archivieren: Ein Datensatz verschwindet aus Standardliste und Auswahlfeld, ist über den Archivfilter auffindbar.
2. Wiederherstellen: Er erscheint wieder in den Standardansichten, mit unveränderten Inhalten.
3. Blockiertes Löschen: Ein Datensatz mit abhängigen Datensätzen lässt sich nicht löschen, die Meldung nennt den Grund.
4. Mitlöschen: Teile eines Datensatzes verschwinden nur mit dem übergeordneten Datensatz, wie festgelegt.
5. Berechtigung: Eine Person ohne Löschrecht kann weder über die Oberfläche noch über einen direkten Aufruf löschen.
6. Zweiter Versuch: Ein erneutes Löschen eines bereits gelöschten Datensatzes erzeugt eine verständliche Meldung, keinen Absturz.
7. Bestätigung: Endgültiges Löschen verlangt eine Bestätigung mit Namen des Datensatzes.

Abnahme Checkliste

Nutzen Sie diese Liste, wenn Sie Akzeptanzkriterien für das Projekt formulieren, und besprechen Sie sie im Gespräch über Web-App Entwicklung für kleine Teams.

• Die drei Zustände sind benannt und in der Oberfläche unterscheidbar.
• Archivierte Datensätze fehlen in Standardlisten und Auswahlfeldern, bleiben aber lesbar.
• Für jede Beziehung ist schriftlich festgelegt, ob blockiert, mitgelöscht oder geleert wird.
• Archivieren, Wiederherstellen und endgültiges Löschen haben getrennte Berechtigungen.
• Endgültiges Löschen verlangt eine Bestätigung mit Namen und Zahl betroffener Datensätze.
• Es ist schriftlich festgehalten, ob und von wem Gelöschtes wiederhergestellt werden kann.
• Das Verhalten bei wiederholtem Löschen ist beschrieben.
• Die Tests mit Testdaten wurden vorgeführt.

FAQs

Reicht es, Datensätze nur zu archivieren?

Für viele kleine Apps ja, es ist die vorsichtigere Wahl. Ob und wann etwas wirklich gelöscht werden muss, hängt von Ihren Pflichten ab. Fragen Sie dazu eine fachkundige Stelle.

Heißt idempotent, dass ein Löschen rückgängig zu machen ist?

Nein. Idempotent beschreibt nur das Verhalten bei Wiederholung. Eine Wiederherstellung müssen Sie getrennt verlangen.

Soll Löschen verknüpfte Datensätze automatisch mitnehmen?

Nur bei Teilen, die ohne den übergeordneten Datensatz keinen Sinn haben. Bei eigenständigen Datensätzen ist Blockieren oder Archivieren meist die vorsichtigere Empfehlung.