Physisches vs. logisches / weiches Löschen des Datenbankeintrags?

Was ist der Vorteil eines logischen / weichen Löschens eines Datensatzes (dh Setzen eines Flags, das angibt, dass der Datensatz gelöscht wurde) im Gegensatz zum tatsächlichen oder physischen Löschen des Datensatzes?

Ist das gängige Praxis?

Ist das sicher?

Der Vorteil besteht darin, dass Sie den Verlauf beibehalten (gut für die Überwachung) und sich nicht darum kümmern müssen, einen Löschvorgang durch verschiedene andere Tabellen in der Datenbank zu kaskadieren, die auf die zu löschende Zeile verweisen. Nachteil ist, dass Sie alle Berichts- / Anzeigemethoden codieren müssen, um das Flag zu berücksichtigen.

Soweit es eine gängige Praxis ist - ich würde ja sagen, aber wie bei allem hängt es von Ihren geschäftlichen Anforderungen ab, ob Sie es verwenden.

BEARBEITEN: Ein weiterer Nachteil: Wenn Sie eindeutige Indizes für die Tabelle haben, nehmen gelöschte Datensätze immer noch den "einen" Datensatz ein, sodass Sie diese Möglichkeit ebenfalls umschreiben müssen (z. B. eine Benutzertabelle mit einem eindeutigen Index Benutzername: Ein gelöschter Datensatz blockiert weiterhin den Benutzernamen des gelöschten Benutzers für neue Datensätze. Wenn Sie dies umgehen, können Sie eine GUID für die Spalte "Gelöschter Benutzername" anheften, aber es ist eine sehr hackige Problemumgehung, die ich nicht empfehlen würde. Wahrscheinlich würde dies unter diesen Umständen der Fall sein Es ist besser, nur die Regel zu haben, dass ein einmal verwendeter Benutzername niemals ersetzt werden kann.)

Sind logische Löschvorgänge üblich? Ja, ich habe das an vielen Orten gesehen. Sind sie sicher? Das hängt wirklich davon ab, ob sie weniger sicher sind als die Daten, bevor Sie sie gelöscht haben.

Als ich ein technischer Leiter war, forderte ich unser Team auf, alle Daten aufzubewahren. Ich wusste zu der Zeit, dass wir all diese Daten zum Erstellen verschiedener BI-Anwendungen verwenden würden, obwohl wir zu diesem Zeitpunkt nicht wussten, welche Anforderungen dies erfüllen würde Sein. Dies war zwar vom Standpunkt der Prüfung, Fehlerbehebung und Berichterstellung aus gut (dies war eine E-Commerce- / Tool-Site für B2B-Transaktionen, und wenn jemand ein Tool verwendete, wollten wir es aufzeichnen, auch wenn sein Konto später deaktiviert wurde). Es hatte mehrere Nachteile.

Die Nachteile sind (ohne andere bereits erwähnte):

1. Leistung Implikationen der Aufbewahrung all dieser Daten, Wir entwickeln verschiedene Archivierungsstrategien. Zum Beispiel war ein Bereich der Anwendung kurz davor, ungefähr 1 GB Daten pro Woche zu generieren.
2. Die Kosten für die Aufbewahrung der Daten steigen mit der Zeit, während der Speicherplatz billig ist, ist die Menge an Infrastruktur für die Aufbewahrung und Verwaltung von Terrabytes an Daten sowohl online als auch offline sehr hoch. Die Redundanz erfordert viel Festplatte und die Zeit der Benutzer, um sicherzustellen, dass die Sicherungen schnell ausgeführt werden.

Wenn ich mich für logische, physische Löschungen oder Archivierung entscheide, stelle ich mir folgende Fragen:

1. Sind dies Daten, die möglicherweise erneut in die Tabelle eingefügt werden müssen. Beispielsweise passen Benutzerkonten zu dieser Kategorie, da Sie möglicherweise ein Benutzerkonto aktivieren oder deaktivieren. In diesem Fall ist ein logisches Löschen am sinnvollsten.
2. Gibt es einen inneren Wert beim Speichern der Daten? Wenn ja, wie viele Daten werden generiert? Abhängig davon würde ich entweder logisch löschen oder eine Archivierungsstrategie implementieren. Beachten Sie, dass Sie logisch gelöschte Datensätze jederzeit archivieren können.

Es mag etwas spät sein, aber ich empfehle jedem, Pinal Daves Blog-Beitrag über logisches / weiches Löschen zu lesen:

Ich mag diese Art von Design [Soft Delete] einfach überhaupt nicht. Ich bin fest davon überzeugt, dass nur die erforderlichen Daten in einer einzigen Tabelle gespeichert und die nutzlosen Daten in eine archivierte Tabelle verschoben werden sollten. Anstatt der Spalte isDeleted zu folgen, empfehle ich die Verwendung von zwei verschiedenen Tabellen: eine mit Bestellungen und eine mit gelöschten Bestellungen. In diesem Fall müssen Sie beide Tabellen pflegen, aber in Wirklichkeit ist es sehr einfach zu pflegen. Wenn Sie eine UPDATE-Anweisung in die Spalte isDeleted schreiben, schreiben Sie INSERT IN eine andere Tabelle und löschen Sie sie aus der ursprünglichen Tabelle. Wenn es sich um einen Rollback handelt, schreiben Sie ein weiteres INSERT INTO und DELETE in umgekehrter Reihenfolge. Wenn Sie sich Sorgen über eine fehlgeschlagene Transaktion machen, schließen Sie diesen Code in TRANSACTION ein.

Was sind die Vorteile der kleineren Tabelle gegenüber der größeren Tabelle in den oben beschriebenen Situationen?

• Ein kleinerer Tisch ist leicht zu pflegen
• Indexwiederherstellungsvorgänge sind viel schneller
• Durch das Verschieben der Archivdaten in eine andere Dateigruppe wird die Last der primären Dateigruppe verringert (wenn man bedenkt, dass sich alle Dateigruppen auf einem anderen System befinden). Dies beschleunigt auch die Sicherung.
• Statistiken werden aufgrund der geringeren Größe häufig aktualisiert und sind weniger ressourcenintensiv.
• Die Größe des Index wird kleiner
• Die Leistung der Tabelle wird mit einer kleineren Tabellengröße verbessert.

Ich bin ein NoSQL-Entwickler und habe bei meinem letzten Job mit Daten gearbeitet, die für jemanden immer kritisch waren. Wenn sie versehentlich am selben Tag gelöscht wurden, an dem sie erstellt wurden, konnte ich sie in der letzten Sicherung nicht finden von gestern! In dieser Situation hat das weiche Löschen immer den Tag gerettet.

Ich habe das Löschen mit Zeitstempeln durchgeführt und das Datum registriert, an dem das Dokument gelöscht wurde:

IsDeleted = 20150310  //yyyyMMdd

Jeden Sonntag ging ein Prozess durch die Datenbank und überprüfte das IsDeletedFeld. Wenn die Differenz zwischen dem aktuellen Datum und dem Zeitstempel größer als N Tage war, wurde das Dokument schwer gelöscht. Da das Dokument in einigen Backups noch verfügbar ist, war dies sicher.

BEARBEITEN: diesem NoSQL-Anwendungsfall geht es um große Dokumente, die in der Datenbank erstellt werden, zehn oder Hunderte davon täglich, aber nicht Tausende oder Millionen. Im Allgemeinen handelte es sich um Dokumente mit Status, Daten und Anhängen von Workflow-Prozessen. Aus diesem Grund bestand die Möglichkeit, dass ein Benutzer ein wichtiges Dokument löscht. Dieser Benutzer kann jemand mit Administratorrechten sein oder der Eigentümer des Dokuments, um nur einige zu nennen.

TL; DR Mein Anwendungsfall war nicht Big Data. In diesem Fall benötigen Sie einen anderen Ansatz.

Ein Muster, das ich verwendet habe, besteht darin, eine Spiegeltabelle zu erstellen und einen Trigger an die Primärtabelle anzuhängen, damit alle Löschungen (und Aktualisierungen, falls gewünscht) in der Spiegeltabelle aufgezeichnet werden.

Auf diese Weise können Sie gelöschte / geänderte Datensätze "rekonstruieren" und in der Primärtabelle immer noch schwer löschen und "sauber" halten. Außerdem können Sie eine "Rückgängig" -Funktion erstellen und Datum und Uhrzeit aufzeichnen und Benutzer, der die Aktion in der Spiegeltabelle ausgeführt hat (von unschätzbarem Wert in Hexenjagdsituationen).

Der andere Vorteil besteht darin, dass beim Abfragen der Primärdaten nicht versehentlich gelöschte Datensätze eingeschlossen werden können, es sei denn, Sie haben sich absichtlich die Mühe gemacht, Datensätze aus der Spiegeltabelle einzuschließen (möglicherweise möchten Sie Live- und gelöschte Datensätze anzeigen).

Ein weiterer Vorteil besteht darin, dass die Spiegeltabelle unabhängig gelöscht werden kann, da sie keine tatsächlichen Fremdschlüsselreferenzen enthalten sollte. Dies ist eine relativ einfache Operation im Vergleich zum Löschen aus einer Primärtabelle, die weiche Löschvorgänge verwendet, aber dennoch referenzielle Verbindungen zu anderen Tabellen aufweist.

Welche weiteren Vorteile? - Großartig, wenn Sie eine Reihe von Programmierern haben, die an dem Projekt arbeiten und mit gemischten Fähigkeiten und Liebe zum Detail in der Datenbank lesen. Sie müssen nicht nachts aufbleiben und hoffen, dass einer von ihnen nicht vergessen hat, nicht gelöscht zu werden Datensätze (lol, Gelöschte Datensätze nicht einschließen = Wahr), die zu einer Überbewertung führen, sagen, dass die Kunden über eine verfügbare Barposition verfügen, mit der sie dann einige Aktien kaufen (dh wie in einem Handelssystem), wenn Sie mit Handelssystemen arbeiten, Sie wird sehr schnell den Wert robuster Lösungen herausfinden, auch wenn sie möglicherweise etwas mehr anfänglichen "Overhead" haben.

Ausnahmen:
- Verwenden Sie als Richtlinie weiche Löschvorgänge für "Referenz" -Daten wie Benutzer, Kategorie usw. und harte Löschvorgänge in einer Spiegeltabelle für Daten vom Typ "Fakt", dh Transaktionsverlauf.

Ich verwende normalerweise logische Löschvorgänge. Ich finde, dass sie gut funktionieren, wenn Sie die "gelöschten" Daten auch zeitweise in einer archivierten Tabelle archivieren (die bei Bedarf durchsucht werden kann), ohne die Leistung der Anwendung zu beeinträchtigen.

Es funktioniert gut, weil Sie immer noch die Daten haben, wenn Sie jemals geprüft werden. Wenn Sie es physisch löschen, ist es weg !

Ich bin ein großer Fan des logischen Löschens, insbesondere für eine Branchenanwendung oder im Kontext von Benutzerkonten. Meine Gründe sind einfach: Oft möchte ich nicht, dass ein Benutzer das System mehr verwenden kann (daher wird das Konto als gelöscht markiert), aber wenn wir den Benutzer löschen, verlieren wir seine gesamte Arbeit und dergleichen.

Ein weiteres häufiges Szenario ist, dass die Benutzer möglicherweise eine Weile nach dem Löschen neu erstellt werden. Es ist für den Benutzer eine viel schönere Erfahrung, alle Daten so zu haben, wie sie vor dem Löschen waren, anstatt sie neu erstellen zu müssen.

Ich denke normalerweise daran, Benutzer zu löschen, indem ich sie auf unbestimmte Zeit "aussetze". Sie wissen nie, wann sie zu Recht zurück sein müssen.

Ich lösche fast immer sanft und hier ist der Grund:

• Sie können gelöschte Daten wiederherstellen, wenn Sie von einem Kunden dazu aufgefordert werden. Mehr zufriedene Kunden mit weichen Löschungen. Das Wiederherstellen bestimmter Daten aus Sicherungen ist komplex
• Das Überprüfen nach isdeletedüberall ist kein Problem. Sie müssen es useridtrotzdem überprüfen (wenn die Datenbank Daten von mehreren Benutzern enthält). Sie können die Prüfung nach Code erzwingen, indem Sie diese beiden Prüfungen einer separaten Funktion zuordnen (oder Ansichten verwenden).
• anmutiges Löschen. Benutzer oder Prozesse, die sich mit gelöschten Inhalten befassen, "sehen" diese weiterhin, bis sie die nächste Aktualisierung durchführen. Dies ist eine sehr wünschenswerte Funktion, wenn ein Prozess einige Daten verarbeitet, die plötzlich gelöscht werden
• Synchronisation: Wenn Sie einen Synchronisationsmechanismus zwischen einer Datenbank und mobilen Apps entwerfen müssen, ist die Implementierung von Soft Deletes viel einfacher

Betreff: "Ist das sicher?" - Das hängt davon ab, was du meinst.

Wenn Sie damit meinen, dass Sie durch physisches Löschen verhindern, dass jemand jemals die gelöschten Daten findet , dann ist das mehr oder weniger wahr. Sie können die vertraulichen Daten, die gelöscht werden müssen, sicherer löschen, da sie dauerhaft aus der Datenbank entfernt werden. (Beachten Sie jedoch, dass möglicherweise andere Kopien der betreffenden Daten vorhanden sind, z. B. eine Sicherung oder das Transaktionsprotokoll oder eine aufgezeichnete Version von unterwegs, z. B. ein Paket-Sniffer - nur weil Sie dies nicht aus Ihrer Datenbank löschen garantiere, dass es nicht woanders gespeichert wurde.)

Wenn Sie damit meinen, dass Ihre Daten durch logisches Löschen sicherer sind, weil Sie niemals Daten verlieren , gilt dies auch. Dies ist gut für Prüfungsszenarien. Ich neige dazu, auf diese Weise zu entwerfen, weil es die grundlegende Tatsache einräumt, dass Daten, sobald sie generiert wurden, nie wirklich verschwinden (insbesondere wenn sie jemals die Fähigkeit hatten, beispielsweise von einer Internet-Suchmaschine zwischengespeichert zu werden). Natürlich erfordert ein echtes Überwachungsszenario, dass nicht nur Löschungen logisch sind, sondern dass Aktualisierungen zusammen mit dem Zeitpunkt der Änderung und dem Akteur, der die Änderung vorgenommen hat, auch protokolliert werden.

Wenn Sie meinen, dass die Daten nicht in die Hände von Personen fallen, die sie nicht sehen sollen, liegt dies ganz bei Ihrer Anwendung und ihrer Sicherheitsstruktur. In dieser Hinsicht ist das logische Löschen nicht mehr oder weniger sicher als alles andere in Ihrer Datenbank.

Ich bin mit dem logischen Löschen nicht einverstanden, da Sie vielen Fehlern ausgesetzt sind.

Zuallererst muss jede Abfrage das Feld IsDeleted berücksichtigen, und die Wahrscheinlichkeit von Fehlern wird bei komplexen Abfragen höher.

Zweitens die Leistung: Stellen Sie sich eine Tabelle mit 100000 Recs mit nur 3 aktiven vor und multiplizieren Sie diese Zahl jetzt mit den Tabellen Ihrer Datenbank. Ein weiteres Leistungsproblem ist ein möglicher Konflikt mit neuen Datensätzen mit alten (gelöschten Datensätzen).

Der einzige Vorteil , den ich sehe , ist die Geschichte der Aufzeichnungen, aber es gibt andere Methoden , um dieses Ergebnis zu erzielen, zum Beispiel Sie eine Logging - Tabelle erstellen können , wo Sie Informationen speichern können: TableName,OldValues,NewValues,Date,User,[..]wo *Valueskann varchardie Details in dieser Form und schreiben fieldname : value; [..] oder speichern Sie die Informationen als xml.

All dies kann über Code oder Trigger erreicht werden, aber Sie sind nur EINE Tabelle mit Ihrem gesamten Verlauf. Eine weitere Option besteht darin, zu überprüfen, ob das angegebene Datenbankmodul native Unterstützung für die Nachverfolgung von Änderungen bietet. Beispielsweise gibt es in der SQL Server-Datenbank SQL Track Data Change.

Früher habe ich Soft-Delete ausgeführt, nur um alte Aufzeichnungen zu führen. Mir wurde klar, dass Benutzer sich nicht die Mühe machen, alte Datensätze so oft anzuzeigen, wie ich dachte. Wenn Benutzer alte Datensätze anzeigen möchten, können sie diese einfach aus dem Archiv oder der Überwachungstabelle anzeigen, oder? Was ist der Vorteil von Soft-Delete? Dies führt nur zu komplexeren Abfrageanweisungen usw.

Im Folgenden sind die Dinge aufgeführt, die ich implementiert habe, bevor ich mich entschied, nicht mehr sanft zu löschen:

1. Implementieren Sie ein Audit, um alle Aktivitäten aufzuzeichnen (Hinzufügen, Bearbeiten, Löschen). Stellen Sie sicher, dass kein Fremdschlüssel mit der Prüfung verknüpft ist, und stellen Sie sicher, dass diese Tabelle gesichert ist und niemand außer Administratoren löschen kann.

2. Identifizieren Sie, welche Tabellen als "Transaktionstabelle" betrachtet werden, welche sehr wahrscheinlich lange aufbewahrt werden und welcher Benutzer möglicherweise die früheren Datensätze oder Berichte anzeigen möchte. Beispielsweise; Kauftransaktion. Diese Tabelle sollte nicht nur die ID der Mastertabelle (z. B. Dept-ID) enthalten, sondern auch die zusätzlichen Informationen wie den Namen als Referenz (z. B. Dept-Name) oder andere für die Berichterstellung erforderliche Felder.

3. Implementieren Sie den Datensatz "Aktiv / Inaktiv" oder "Aktivieren / Deaktivieren" oder "Ausblenden / Anzeigen" der Mastertabelle. Anstatt den Datensatz zu löschen, kann der Benutzer den Stammdatensatz deaktivieren / inaktivieren. Auf diese Weise ist es viel sicherer.

Nur meine zwei Cent Meinung.

Logische Löschungen, wenn die referenzielle Integrität stark beeinträchtigt wird.

Es ist richtig zu denken, wenn es einen zeitlichen Aspekt der Tabellendaten gibt (gültig von FROM_DATE - TO_DATE).

Andernfalls verschieben Sie die Daten in eine Überwachungstabelle und löschen Sie den Datensatz.

Auf der positiven Seite:

Es ist der einfachere Weg zum Rollback (wenn überhaupt möglich).

Es ist leicht zu erkennen, wie der Zustand zu einem bestimmten Zeitpunkt war.

Es ist ziemlich normal in Fällen, in denen Sie einen Verlauf von etwas führen möchten (z. B. Benutzerkonten, wie @ Jon Dewees erwähnt). Und es ist sicherlich eine großartige Idee, wenn die Wahrscheinlichkeit groß ist, dass Benutzer nach Löschungen fragen.

Wenn Sie sich Sorgen über die Logik machen, die gelöschten Datensätze aus Ihren Abfragen herauszufiltern, die unübersichtlich werden und Ihre Abfragen nur komplizieren, können Sie einfach Ansichten erstellen, die die Filterung für Sie durchführen, und Abfragen dagegen verwenden. Dadurch wird verhindert, dass diese Datensätze in Berichtslösungen und dergleichen verloren gehen.

Über das Systemdesign hinaus gibt es Anforderungen, die beantwortet werden müssen. Was ist die gesetzliche oder gesetzliche Anforderung bei der Aufbewahrung von Unterlagen? Abhängig davon, worauf sich die Zeilen beziehen, kann es gesetzlich vorgeschrieben sein, dass die Daten für einen bestimmten Zeitraum aufbewahrt werden, nachdem sie "ausgesetzt" wurden.

Andererseits kann die Anforderung sein, dass der Datensatz, sobald er "gelöscht" wurde, wirklich und unwiderruflich gelöscht wird. Bevor Sie eine Entscheidung treffen, sprechen Sie mit Ihren Stakeholdern.

Mobile Apps, die von der Synchronisierung abhängen, erfordern möglicherweise eher die Verwendung eines logischen als eines physischen Löschvorgangs: Ein Server muss dem Client anzeigen können, dass ein Datensatz (als) gelöscht wurde, und dies ist möglicherweise nicht möglich, wenn Datensätze physisch gelöscht wurden.

Sie lassen die Datenbank nicht so funktionieren, wie sie sollte, wodurch solche Dinge wie die Kaskadenfunktionalität unbrauchbar werden.

Bei einfachen Dingen wie Einfügungen verdoppelt sich beim erneuten Einfügen der Code dahinter.

Sie können nicht einfach einfügen, sondern müssen nach einer Existenz suchen und einfügen, wenn sie vorher nicht vorhanden war, oder das Löschflag aktualisieren, wenn dies der Fall ist, und gleichzeitig alle anderen Spalten auf die neuen Werte aktualisieren. Dies wird als Aktualisierung des Datenbanktransaktionsprotokolls und nicht als neue Einfügung angesehen, die zu ungenauen Überwachungsprotokollen führt.

Sie verursachen Leistungsprobleme, da Tabellen mit redundanten Daten überfüllt sind. Es spielt eine Rolle bei der Indizierung, insbesondere bei der Einzigartigkeit.

Ich bin kein großer Fan von logischen Löschungen.

Um auf Tohids Kommentar zu antworten, standen wir vor dem gleichen Problem, bei dem wir die Geschichte der Aufzeichnungen beibehalten wollten, und wir waren uns auch nicht sicher, ob wir eine is_deletedKolumne wollten oder nicht.

Ich spreche über unsere Python-Implementierung und einen ähnlichen Anwendungsfall, den wir getroffen haben.

Wir haben https://github.com/kvesteri/sqlalchemy-continuum gefunden, mit dem Sie auf einfache Weise die Versionierungstabelle für Ihre entsprechende Tabelle abrufen können. Minimale Codezeilen und erfasst den Verlauf zum Hinzufügen, Löschen und Aktualisieren.

Dies dient mehr als nur einer is_deletedSpalte. Sie können die Versionstabelle jederzeit zurückverweisen, um zu überprüfen, was mit diesem Eintrag passiert ist. Ob der Eintrag gelöscht, aktualisiert oder hinzugefügt wurde.

Auf diese Weise brauchten wir überhaupt keine is_deletedSpalte und unsere Löschfunktion war ziemlich trivial. Auf diese Weise müssen wir uns auch nicht daran erinnern, is_deleted=Falsein einer unserer APIs zu markieren .

Soft Delete ist eine Programmierpraxis, die in den meisten Anwendungen angewendet wird, wenn Daten relevanter sind. Stellen Sie sich einen Fall einer Finanzanwendung vor, bei dem ein Löschen durch den Fehler des Endbenutzers schwerwiegend sein kann. Dies ist der Fall, wenn Soft Delete relevant wird. Beim Soft-Löschen löscht der Benutzer die Daten nicht aus dem Datensatz, sondern wird als IsDeleted als true gekennzeichnet (gemäß normaler Konvention).

Ab EF 6.x oder EF 7 wird Softdelete als Attribut hinzugefügt, wir müssen jedoch vorerst ein benutzerdefiniertes Attribut erstellen.

Ich empfehle SoftDelete dringend in einem Datenbankdesign und es ist eine gute Konvention für die Programmierpraxis.

Meistens wird Softdeleting verwendet, weil Sie einige Daten nicht verfügbar machen möchten, sie jedoch aus historischen Gründen aufbewahren müssen (Ein Produkt könnte eingestellt werden, sodass Sie keine neue Transaktion damit möchten, aber dennoch damit arbeiten müssen die Geschichte der Verkaufstransaktion). Übrigens kopieren einige den Produktinformationswert in die Verkaufstransaktionsdaten, anstatt auf das Produkt zu verweisen, um dies zu handhaben.

Tatsächlich sieht es eher nach einer Umformulierung für eine sichtbare / versteckte oder aktive / inaktive Funktion aus. Denn das ist die Bedeutung von "Löschen" in der Geschäftswelt. Ich möchte sagen, dass Terminatoren Leute löschen können, aber der Chef sie einfach feuert.

Diese Praxis ist ein weit verbreitetes Muster und wird von vielen Anwendungen aus vielen Gründen verwendet. Da dies nicht der einzige Weg ist, dies zu erreichen, werden Tausende von Menschen sagen, dass das großartig oder beschissen ist, und beide haben ziemlich gute Argumente.

Aus Sicherheitsgründen ersetzt SoftDelete nicht den Job von Audit und auch nicht den Job von Backup. Wenn Sie Angst vor dem "Einfügen / Löschen zwischen zwei Sicherungsfällen" haben, sollten Sie sich über vollständige oder Massenwiederherstellungsmodelle informieren. Ich gebe zu, dass SoftDelete den Wiederherstellungsprozess trivialer machen könnte.

Es liegt an Ihnen, Ihre Anforderungen zu kennen.

Als Alternative haben wir Benutzer, die Remote-Geräte verwenden, die über MobiLink aktualisiert werden. Wenn wir Datensätze in der Serverdatenbank löschen, werden diese Datensätze in den Clientdatenbanken niemals als gelöscht markiert.

Also machen wir beides. Wir arbeiten mit unseren Kunden zusammen, um festzustellen, wie lange sie Daten wiederherstellen möchten. Beispielsweise sind Kunden und Produkte im Allgemeinen so lange aktiv, bis unser Kunde sagt, dass sie gelöscht werden sollen. Die Umsatzhistorie wird jedoch nur 13 Monate lang gespeichert und dann automatisch gelöscht. Der Kunde möchte möglicherweise gelöschte Kunden und Produkte zwei Monate lang aufbewahren, den Verlauf jedoch sechs Monate lang aufbewahren.

Wir führen also über Nacht ein Skript aus, das Dinge markiert, die gemäß diesen Parametern logisch gelöscht wurden. Zwei oder sechs Monate später wird alles, was heute als logisch gelöscht markiert ist, schwer gelöscht.

Bei uns geht es weniger um Datensicherheit als darum, riesige Datenbanken auf einem Clientgerät mit begrenztem Speicher wie einem Smartphone zu haben. Ein Kunde, der vier Jahre lang zweimal pro Woche 200 Produkte bestellt, verfügt über mehr als 81.000 Zeilen Geschichte, von denen 75% dem Kunden egal sind, ob er sie sieht.

Es hängt alles vom Anwendungsfall des Systems und seinen Daten ab.

Wenn Sie beispielsweise von einem staatlich regulierten System sprechen (z. B. einem System eines Pharmaunternehmens, das als Teil des Qualitätssicherungssystems betrachtet wird und den FDA-Richtlinien für elektronische Aufzeichnungen entsprechen muss), sollten Sie verdammt noch mal keine harten Löschvorgänge durchführen! Ein Auditor der FDA kann hereinkommen und alle Aufzeichnungen im System in Bezug auf die Produktnummer ABC-123 anfordern, und alle Daten sollten besser verfügbar sein. Wenn Ihr Geschäftsprozessverantwortlicher angibt, dass das System künftig niemandem erlauben sollte, die Produktnummer ABC-123 für neue Datensätze zu verwenden, verwenden Sie stattdessen die Soft-Delete-Methode, um sie im System "inaktiv" zu machen, während die historischen Daten erhalten bleiben.

Möglicherweise hat Ihr System und seine Daten jedoch einen Anwendungsfall wie "Verfolgen des Wetters am Nordpol". Vielleicht nehmen Sie einmal pro Stunde Temperaturmessungen vor und summieren am Ende des Tages einen Tagesdurchschnitt. Möglicherweise werden die stündlichen Daten nach der Aggregation nicht mehr verwendet, und Sie würden die stündlichen Messwerte nach dem Erstellen des Aggregats schwer löschen. (Dies ist ein erfundenes, triviales Beispiel.)

Der Punkt ist, dass alles vom Anwendungsfall des Systems und seiner Daten abhängt und nicht von einer Entscheidung, die nur aus technologischer Sicht getroffen werden muss.

Gut! Wie jeder sagte, kommt es auf die Situation an.

Wenn Sie einen Index für eine Spalte wie Benutzername oder E-Mail-ID haben und nie erwarten, dass derselbe Benutzername oder die gleiche E-Mail-ID erneut verwendet wird; Sie können mit einem weichen Löschen gehen.

Überprüfen Sie jedoch immer, ob Ihre SELECT-Operation den Primärschlüssel verwendet. Wenn Ihre SELECT-Anweisung einen Primärschlüssel verwendet, macht das Hinzufügen eines Flags mit der WHERE-Klausel keinen großen Unterschied. Nehmen wir ein Beispiel (Pseudo):

Tabellenbenutzer (UserID [Primärschlüssel], EmailID, IsDeleted)

SELECT * FROM Users where UserID = 123456 and IsDeleted = 0

Diese Abfrage hat keinen Einfluss auf die Leistung, da die UserID-Spalte einen Primärschlüssel enthält. Zunächst wird die Tabelle basierend auf PK gescannt und dann die nächste Bedingung ausgeführt.

Fälle, in denen weiche Löschvorgänge überhaupt nicht funktionieren:

Bei der Anmeldung auf fast allen Websites wird EmailID als eindeutige Identifikation verwendet. Wir wissen sehr gut, dass eine E-Mail-ID, die auf einer Website wie Facebook, G + verwendet wird, von niemand anderem verwendet werden kann.

Es kommt ein Tag, an dem der Benutzer sein Profil von der Website löschen möchte. Wenn Sie jetzt eine logische Löschung vornehmen, kann sich dieser Benutzer nie wieder registrieren. Eine erneute Registrierung mit derselben E-Mail-ID würde auch nicht bedeuten, den gesamten Verlauf wiederherzustellen. Jeder weiß, Löschen bedeutet Löschen. In solchen Szenarien müssen wir einen physischen Löschvorgang durchführen. Um jedoch den gesamten Verlauf des Kontos zu erhalten, sollten wir solche Datensätze immer entweder in Archivtabellen oder in gelöschten Tabellen archivieren.

Ja, in Situationen, in denen wir viele fremde Tabellen haben, ist die Handhabung ziemlich umständlich.

Beachten Sie auch, dass weiche / logische Löschvorgänge Ihre Tabellengröße und damit die Indexgröße erhöhen.

Ich habe bereits in einem anderen Beitrag geantwortet . Ich denke jedoch, dass meine Antwort hier besser zu der Frage passt.

Meine praktische Lösung für Soft-Lösch ist die Archivierung durch eine neue Tabelle mit folgenden Spalten zu erstellen: original_id, table_name,payload , (und ein optionaler Primärschlüssel `id).

Wo original_idist die ursprüngliche ID des gelöschten Datensatzes, table_name ist der Tabellenname des gelöschten Datensatzes ( "user"in Ihrem Fall), payload ist JSON-Zeichenfolge aus allen Spalten des gelöschten Datensatzes.

Ich schlage auch vor, einen Index für die Spalte zu erstellen original_id zu erstellen letztere Daten abgerufen werden können.

Auf diese Weise werden Daten archiviert. Sie werden diese Vorteile haben

• Behalten Sie alle Daten im Verlauf im Auge
• Sie können nur einen Ort zum Archivieren von Datensätzen aus einer Tabelle verwenden, unabhängig von der Tabellenstruktur des gelöschten Datensatzes
• Keine Sorge vor einem eindeutigen Index in der Originaltabelle
• Keine Sorge, den Fremdindex in der Originaltabelle zu überprüfen
• Keine WHEREKlausel mehr in jeder Abfrage, um das Löschen zu überprüfen

Das ist schon eine Diskussion hier zu erklären , warum Soft-Löschung nicht eine gute Idee , in der Praxis ist. Soft-Delete führt in Zukunft zu potenziellen Problemen wie dem Zählen von Datensätzen, ...

Abenteuer sind Datenerhaltung / -erhaltung. Ein Nachteil wäre eine Leistungsminderung beim Abfragen oder Abrufen von Daten aus Tabellen mit einer signifikanten Anzahl von weichen Löschvorgängen. In unserem Fall verwenden wir eine Kombination aus beiden: Wie andere bereits in früheren Antworten erwähnt haben, soft-delete users/clients/customersbeispielsweise hard-deletein items/products/merchandiseTabellen, in denen es doppelte Datensätze gibt, die nicht aufbewahrt werden müssen.

Es hängt vom Fall ab, beachten Sie Folgendes:

Normalerweise müssen Sie einen Datensatz nicht "sanft löschen". Halte es einfach und schnell. Beispiel: Das Löschen eines Produkts ist nicht mehr verfügbar, sodass Sie nicht überprüfen müssen, ob das Produkt in Ihrer gesamten App (Anzahl, Produktliste, empfohlene Produkte usw.) nicht gelöscht wird.

Sie können jedoch das "Soft-Delete" in einem Data-Warehouse-Modell in Betracht ziehen. Beispiel: Sie sehen eine alte Quittung für ein gelöschtes Produkt. *