web-dev-qa-db-de.com

Sind weiche Löschvorgänge eine gute Idee?

Sind weiche Löschvorgänge eine gute oder eine schlechte Idee?

Anstatt einen Datensatz in Ihrer Datenbank tatsächlich zu löschen, markieren Sie ihn einfach als IsDeleted = true, und nach Wiederherstellung des Datensatzes können Sie ihn einfach als False kennzeichnen.

Ist das eine gute Idee?

Ist es eine bessere Idee, den Datensatz physisch zu löschen und ihn dann in eine Archivdatenbank zu verschieben, und wenn der Benutzer den Datensatz zurück haben möchte, sucht die Software nach dem Datensatz im Archiv und erstellt ihn neu?

136
001

Ich sage, es ist im Allgemeinen eine schlechte Idee (mit einigen Ausnahmen vielleicht).

Erstens sollte Ihre Datenbank regelmäßig gesichert werden, damit Sie nie in einer Situation sind, in der Sie aufgrund eines LÖSCHENS dauerhaft Daten verlieren würden (es sei denn, es handelt sich natürlich um das Löschen gerade hinzugefügter Daten).

Zweitens bedeutet ein vorläufiges Löschen, dass Sie jetzt in jede Abfrage dieser Tabelle eine WHERE IsDeleted = false - Klausel einfügen müssen (und noch viel schlimmer, wenn Sie diese Tabellen beitreten). Ein Fehler wird hier abgefangen, sobald ein Benutzer oder Tester feststellt, dass ein gelöschter Datensatz erneut angezeigt wird, was einige Zeit in Anspruch nehmen kann. Außerdem könnte ein Entwickler die WHERE-Klausel in COUNT (*) -Anfragen einfach weglassen, was noch länger dauern könnte. (Ich habe an einem Projekt gearbeitet, in dem dies jahrelang passiert war. Nicht viele Datensätze wurden jemals "gelöscht".) (Die Gesamtsummen lagen also nahe an den Erwartungen, und niemand bemerkte dies).

Schließlich funktioniert ein Soft Delete für eine Tabelle mit künstlichen Schlüsseln, möglicherweise jedoch nicht für eine Tabelle mit einem natürlichen Primärschlüssel (z. B. "löschen" Sie jemanden aus einer Tabelle, die mit einer Sozialversicherungsnummer versehen ist - was tun Sie, wenn Sie dies tun? Möchten Sie ihn wieder hinzufügen? Sagen Sie nicht "IsDeleted in einen zusammengesetzten Primärschlüssel aufnehmen".).

In einer Entwurfsprüfung würde ich erwarten, dass der Entwickler ein Bewusstsein für die Kosten und den Nutzen zeigt und einen ausgezeichneten Grund für das Ausführen von weichen Löschungen auf diese Weise vorlegt. "Warum nicht es tun?" ist kein guter Grund.

100
MusiGenesis

Es ist nie eine schlechte Idee, potenziellen Datenverlust zu vermeiden.

Ich lösche immer sanft. In Fällen, in denen die Datenbank von einem oder mehreren Datensätzen gescrubbt werden muss, verwende ich im Allgemeinen entweder einen zweistufigen Prozess des vorläufigen Löschens und anschließenden Leerens eines "Papierkorbs" von Datensätzen oder einen Ansatz im Stil der Dokumentverwaltung, bei dem Dokumentdatensätze möglich sind vor dem endgültigen Löschen einen Genehmigungsprozess durchlaufen.

93
Robert Harvey

Das hängt von den Umständen ab. Ich sehe Situationen, in denen Sie gesetzlich dazu verpflichtet sind, wirklich etwas zu löschen. Vielleicht hat jemand beantragt, dass seine Sozialversicherungsnummer dauerhaft von Ihrem System entfernt wird. Oder Sie haben einen doppelten Datensatz, den Sie in einem einzelnen Datensatz zusammenfassen möchten. Es ist möglicherweise nicht vorteilhaft, das Duplikat mit einer gelöschten Markierung herumzuhängen.

Es gibt auch einen technischen Nachteil: Sie können keine kaskadierenden Löschvorgänge ausführen, bei denen automatisch alle Verweise auf die gelöschten Daten gelöscht werden, um Verletzungen von Fremdschlüsseln zu verhindern. Dies ist nicht unbedingt ein großes Problem, aber es ist etwas zu beachten.

Ansonsten halte ich es für eine gute Idee.

32
devuxer

Wenn Sie das weiche Löschen verwenden, ist es eine gute Idee, ein Feld für das gelöschte_Datum anstelle eines Felds für das gelöschte_Datum zu verwenden. Sie erhalten ein schönes Stück zusätzlicher Daten anstelle nur des Bitfeldes.

24
Josh Smeaton

Eines der Hauptprobleme beim vorläufigen Löschen ist, dass unerwünschte Daten möglicherweise die Datenbankleistung beeinträchtigen. Vor einigen Jahren forderte mich einer meiner Kunden auf, alle Datenbankelemente vorläufig zu löschen. Meine Lösung besteht darin, alle "gelöschten" Elemente in eine Sicherungstabelle zu verschieben, anstatt sie den aktuell ausgeführten Tabellen zu überlassen.

20
xandy

Es ist eine gute Idee, wann und ob ein ungültiges Löschen absolut katastrophal ist und die Wiederherstellung einfach sein sollte. Es ist auch eine gute Idee, wenn Sie alles im Auge behalten möchten, was jemals war, und "Löschen" wirklich nur "Verstecken" bedeutet. Das heißt, es liegt an der Situation.

17
Anthony Pegram

Ich werde nicht versuchen, "politisch korrekt zu sein". Wenn Sie Soft-Delete befürworten, müssen Sie sich einer Gehirnuntersuchung unterziehen.

1) Was genau erreichen Sie, wenn Sie die Zeilen in der Tabelle nicht löschen? Nur die Tatsache, dass Sie irgendwann in Zukunft auf diese Zeilen zugreifen können, oder? Warum also nicht einfach eine Archivtabelle erstellen und die Zeilen dorthin verschieben? was stimmt damit nicht?

2) Mit Soft-Delete erstellen Sie eine unnötige Abfrage für is_active oder eine Abfrage für eine Zeitstempelspalte. Das ist nur Verschwendung, wenn Sie einfachere Abfragen schreiben würden. Ja, es funktioniert mit einer Ansicht, aber sind Ansichten kein zusätzlicher Anhang? Jede Ansicht ist eine zusätzliche SQL, ein zusätzlicher Leistungsaufwand. In jedem kommerziellen RDBMS ist alles nur eine Tabelle. Ansichten haben nichts Magisches an sich, außer der Tatsache, dass Sie nicht wissen, wie Abfragen über Tabellen geschrieben werden.

3) Ja, es funktioniert mit View oder MV. Aber dann habe ich in der Produktion Fragen zu FTS gesehen und alles funktioniert immer noch! Die Wunder moderner Hardware und solider Software. Aber das macht es auch nicht richtig. Nach der gleichen Logik heißt das nicht, dass es RICHTIG ist, nur weil es funktioniert

4) Die Komplexität des Soft-Löschens hört niemals bei einer einfachen Auswahl auf.

A) Angenommen, Sie hatten eine EINZIGARTIGE Einschränkung. Jetzt löschen Sie eine Zeile vorläufig, aber die Spalte mit der UNIQUE-Einschränkung ist noch vorhanden. Wenn Sie dieselben Daten wieder hinzufügen möchten, können Sie dies nicht ohne zusätzliche "Tricks" tun.

B) Möglicherweise haben Sie Verknüpfungen zwischen Tabelle A und Tabelle B, und wenn Sie etwas aus Tabelle A löschen, müssen Sie sicherstellen, dass unabhängige Abfragen in Tabelle B dies berücksichtigen. Angenommen, eine typische Detailseite hat an einer detail_id gearbeitet.

Jetzt wird eine master_id vorläufig gelöscht, aber Sie haben immer noch überall Permalinks mit der detail_id dieser master_id. Wenn Sie master_id hart löschen, sind diese Details einfach nicht vorhanden. Jetzt mit soft delete sind sie noch vorhanden und müssen sich der Tatsache bewusst sein, dass sich ihre master_id im soft delete-Modus befindet.

es wird nicht bei einer einfachen Table_A.is_active = 0 oder 1-Stufe angehalten.

5) Hartes Löschen ist einfach und richtig.

A) Niemand muss irgendwo etwas hinzufügen oder sich Sorgen machen.

  1. Ihre Anwendungslogik ist einfacher
  2. Ihre Datenbank ist kleiner
  3. Ihre Anfragen sind schneller

Archivieren Sie einfach die Daten + verwandten Teile und Sie sollten gut sein.

9
rjha94

Durch vorsichtiges Löschen können Sie auch die Berechtigungen widerrufenDELETE für das von der Anwendung verwendete Datenbankkonto verwenden.

8
Daniel Vassallo

Manchmal sind vorsichtige Löschvorgänge erforderlich. Angenommen, Sie haben eine Rechnungstabelle, die auf eine Produkttabelle verweist. Sobald Sie eine Rechnung mit einem bestimmten Produkt erstellt haben, können Sie dieses Produkt niemals löschen (und wenn Ihr RI korrekt eingerichtet ist, können Sie dies nicht tun).

In diesem speziellen Szenario wird davon ausgegangen, dass Sie die Rechnungen niemals löschen möchten. In einem realen Unternehmen möchten Sie wahrscheinlich keine historischen Finanzdaten löschen.

Es gibt jedoch auch viele andere Fälle, in denen Sie einige Daten nicht löschen können, da eine Abhängigkeit in der Kette aus geschäftlichen oder anderen Gründen nicht löschbar ist.

5
joshperry

wenn Sie in Oracle den Primärschlüssel zu einer von Ihnen erstellten recycle_bin-Tabelle hinzufügen und dann eine Sicherheitsrichtlinie auf Zeilenebene hinzufügen, können Sie die Werte aller Abfragen unterdrücken, wenn sich die Zeile im Papierkorb befindet, und den pk aus dem Papierkorb entfernen stellt automatisch alle Daten wieder her. Sie müssen Ihre anderen Abfragen nicht ändern, um der Logik Rechnung zu tragen.

4
Randy

Das hängt von den Daten ab. Einige Daten können aufgrund gesetzlicher Bestimmungen/Prüfungsanforderungen nicht gelöscht werden.

Auf Social Networking-Sites hingegen kann sollte eine Option zum Löschen eines Kontos mit allen zugehörigen Daten, einschließlich Kontaktinformationen, Fotos, Nachrichten usw., bereitgestellt werden. Facebook.

4
armandino

Dies ist jedoch mit Kosten verbunden, da Sie Ihre Abfragen und Indizes aktualisieren müssen, um die gelöschten Zeilen ausschließen zu können.

Anstatt eine Fahne umzuschalten, verschieben Sie sie möglicherweise in einen anderen "Mülleimer" -Tisch.

Man könnte auch sagen, dass dies nur eine Teillösung ist, da sie nur Löschvorgänge abdeckt. Wenn Sie jedoch eine Zeile aktualisieren, überschreiben Sie weiterhin den alten Wert.

Im Allgemeinen würde ich sagen, lösche niemals etwas, es sei denn, du musst es wirklich. Speicherplatz ist heutzutage billig. Natürlich gibt es Grenzen, es gibt Daten, zu deren Löschung Sie gesetzlich verpflichtet sind, es gibt Daten, die wirklich nicht so wichtig sind, und vielleicht müssen Sie die alten Daten nicht online und in derselben Tabelle (irgendwo in einem Archiv) aufbewahren würde auch funktionieren).

3
Thilo

Nur um einen Cent hinzuzufügen. Ich lösche immer leise; es kostet zwar die leistung, aber sehr wenig. Denken Sie an die Kosten, wenn Ihre Kunden sich über Ihre Software beschweren, die nicht mehr funktioniert, nachdem sie bestimmte Aktionen ausgeführt hat, an die sich selbst sie nicht erinnern kann. Nun, dies mag ein dickes Beispiel sein, aber Sie würden nie wissen, was schief gelaufen ist, wer was getan hat, was vorher war und was danach eingefügt wurde. In diesem Fall wäre das praktisch. Diese Funktionalität ist praktisch für Prüfzwecke und für viele Kunden, die derartige Prüfberichte anfordern.

In den meisten Workflow-basierten Anwendungen ist es eine Softwarefunktion/-anforderung, dass der Kunde an den "Aktionen" interessiert ist, die für ein Arbeitselement ausgeführt werden. welche Werte wurden vergeben und wer hat sie verarbeitet usw.

1
KMån

Ich bin ein Fan von Soft-Deletes. In erster Linie, um kaskadierende Löschvorgänge zu verhindern. Es wird jedoch zusätzlicher Code benötigt, damit beim AUSWÄHLEN eines untergeordneten Objekts eine Verknüpfung mit dem übergeordneten Objekt (und allen übergeordneten Objekten!) Hergestellt wird, um sicherzustellen, dass keines davon gelöscht wird. Alternativ können Sie das Soft-Delete kaskadieren, aber wenn Sie sie später wiederherstellen möchten, wissen Sie möglicherweise nicht, welche Kinder bereits gelöscht wurden und welche aufgrund der Kaskade gelöscht wurden.

Außerdem behalte ich für jedes Objekt ein Änderungsdatum und einen Änderungsbenutzernamen, damit ich weiß, wer es zuletzt geändert (oder vorläufig gelöscht) hat. Dann erstelle ich für einen Audit-Trail eine * History-Tabelle (wie CustomerHistory), die nach jedem UPDATE der Originaltabelle eingefügt wird. Auf diese Weise habe ich nach dem Ändern oder Löschen eines Objekts eine Aufzeichnung darüber, wer die Aktion ausgeführt hat, sowie den letzten bekannten Status des Objekts.

0
Brad Nabholz

In den folgenden allgemeinen Szenarien sind Soft-Deletes aufgetreten:

FALL 1: Entfernen Sie den Datensatz aus der Sichtbarkeit von Benutzer/Code, haben Sie ihn jedoch auf DB-Ebene, da das Unternehmen wissen möchte, dass er über diese Datensätze verfügt.
Diese Anforderungen werden hauptsächlich vom Unternehmen bestimmt. In der Regel besteht im Kern eine rechtliche Anforderung (wie in @ joshperry & @ armandino-Szenarien), den vorherigen Datensatz in der Datenbank zu haben und für jede vorgenommene Änderung einen neuen Datensatz zu erstellen. An dieser Stelle würde ich mir FALL 2 ansehen und bewerten, ob er die Anforderungen erfüllt, bevor ich ein IsDeleted-Flag erhalte

FALL 2: Audit-Trails, um die Entwicklung einer Aufzeichnung zu verfolgen - Es gibt Tonnen anständiger Artikel online, um Audit-Trails von Aufzeichnungen in einer Datenbank zu führen

HTH.

0
Sunny