it-swarm.com.de

Physisches vs. logisches/weiches Löschen des Datenbanksatzes

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

Ist das gängige Praxis?

Ist das sicher?

89
user21826

Die Vorteile sind, dass Sie den Verlauf beibehalten (gut für die Überwachung), und Sie müssen sich keine Sorgen machen, dass ein Löschvorgang durch verschiedene andere Tabellen in der Datenbank geleitet wird, die auf die Zeile verweisen, die Sie löschen. Nachteil ist, dass Sie alle Berichts-/Anzeigemethoden codieren müssen, um die Markierung zu berücksichtigen.

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

BEARBEITEN: Gedanke an einen anderen Nachteil - Wenn Sie eindeutige Indizes für die Tabelle haben, nehmen gelöschte Datensätze immer noch den "Eins" -Datensatz in Anspruch. Daher müssen Sie auch diese Möglichkeit verwenden (z. B. eine User-Tabelle, für die ein eindeutiger Index verwendet wird) Benutzername: Ein gelöschter Datensatz würde immer noch den Benutzernamen der gelöschten Benutzer für neue Datensätze blockieren. Um dies umzugehen, könnten Sie eine GUID an die Spalte mit dem gelöschten Benutzernamen anheften, aber es ist eine sehr harte Workaround, die ich nicht empfehlen könnte In diesem Fall wäre es besser, eine Regel zu haben, die besagt, dass ein Benutzername nie mehr verwendet werden kann.)

58
Chris Shaffer

Sind logische Löschungen gängige Praxis? 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 Tech Lead war, forderte ich von unserem Team auf, alle Daten aufzubewahren. Ich wusste zu diesem Zeitpunkt, dass wir alle diese Daten für die Erstellung verschiedener BI-Anwendungen verwenden würden, obwohl wir zu diesem Zeitpunkt nicht wussten, welche Anforderungen dies erfüllen würden Sein. Dies war zwar vom Standpunkt der Prüfung, Fehlerbehebung und Berichterstellung aus gut (Dies war eine E-Commerce-/Tools-Website für B2B-Transaktionen. Wenn jemand ein Tool verwendete, wollten wir es aufzeichnen, auch wenn sein Konto später deaktiviert wurde.) es hatte einige nachteile.

Die Nachteile umfassen (ohne die bereits erwähnten):

  1. Auswirkungen der Aufbewahrung all dieser Daten, Wir entwickeln verschiedene Archivierungsstrategien. Zum Beispiel war ein Bereich der Anwendung in der Nähe, rund 1 GB Daten pro Woche zu generieren. 
  2. Die Kosten für die Datenhaltung steigen mit der Zeit, während der Speicherplatz günstig ist. Die Menge an Infrastruktur, um Terrabytes an Daten sowohl online als auch offline zu halten und zu verwalten, ist enorm. Die Redundanz erfordert viel Speicherplatz und die Zeit der Benutzer, um sicherzustellen, dass sich die Backups schnell bewegen usw.

Bei der Entscheidung für logisches, physisches Löschen oder Archivieren würde ich mir folgende Fragen stellen:

  1. Müssen diese Daten möglicherweise erneut in die Tabelle eingefügt werden? Zum Beispiel passen Benutzerkonten in diese Kategorie, da Sie ein Benutzerkonto aktivieren oder deaktivieren können. In diesem Fall ist ein logisches Löschen am sinnvollsten.
  2. Gibt es einen inneren Wert bei der Speicherung der Daten? Wenn ja, wie viele Daten generiert werden. Abhängig davon würde ich entweder logisch löschen oder eine Archivierungsstrategie implementieren. Denken Sie daran, dass Sie logisch gelöschte Datensätze immer archivieren können. 
24
JoshBerke

Es könnte etwas spät sein, aber ich schlage vor, dass alle Pinal Daves Blogbeitrag über logisches/weiches Löschen überprüft werden:

Ich mag diese Art von Design überhaupt nicht. Ich glaube fest an die Architektur, bei der nur die erforderlichen Daten in einer einzigen Tabelle enthalten sein sollten und die unbrauchbaren Daten in eine archivierte Tabelle verschoben werden sollten. Statt der Spalte isDeleted zu folgen, schlage ich vor, zwei verschiedene Tabellen zu verwenden: eine mit Aufträgen und eine andere mit gelöschten Aufträgen. In diesem Fall müssen Sie beide Tabellen pflegen, aber in Wirklichkeit ist es sehr einfach zu pflegen. Wenn Sie die UPDATE-Anweisung in die Spalte isDeleted schreiben, schreiben Sie INSERT IN in eine andere Tabelle, und löschen Sie sie aus der ursprünglichen Tabelle. Wenn es sich um ein Rollback handelt, schreiben Sie ein anderes INSERT INTO und DELETE in umgekehrter Reihenfolge. Wenn Sie sich Sorgen wegen einer fehlgeschlagenen Transaktion machen, wickeln Sie diesen Code in TRANSACTION ein.

Welche Vorteile bietet der kleinere Tisch gegenüber dem größeren Tisch 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 Belastung der primären Dateigruppe verringert (in Anbetracht der Tatsache, dass sich alle Dateigruppen auf unterschiedlichen Systemen befinden). Dadurch wird auch die Sicherung beschleunigt.
  • Statistiken werden aufgrund einer kleineren Größe häufig aktualisiert und dies ist weniger Ressourcenintensität.
  • Die Größe des Index wird kleiner sein
  • Die Leistung der Tabelle wird mit einer kleineren Tabellengröße verbessert.
14
Tohid

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

Ich löschte das Löschen mit Zeitstempeln und registrierte das Datum, an dem das Dokument gelöscht wurde:

IsDeleted = 20150310  //yyyyMMdd

Jeden Sonntag lief ein Prozess in der Datenbank ab und überprüfte das Feld IsDeleted. Wenn die Differenz zwischen dem aktuellen Datum und dem Zeitstempel größer als N Tage war, wurde das Dokument hart gelöscht. Da das Dokument für einige Backups noch verfügbar ist, war es sicher, es zu tun.

EDIT: Bei diesem NoSQL-Anwendungsfall handelt es sich um große Dokumente, die in der Datenbank erstellt werden, jeden Tag Dutzende oder Hunderte davon, aber nicht Tausende oder Millionen. Im Allgemeinen handelt 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. Bei diesem Benutzer kann es sich um jemanden mit Administratorrechten oder um den Eigentümer des Dokuments handeln, um nur einige zu nennen.

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

12
Mario S

Ein Muster, das ich verwendet habe, ist das Erstellen einer Spiegeltabelle und das Anhängen eines Auslösers an die Primärtabelle, sodass 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 Sie können sie in der Primärtabelle immer noch hart löschen und "sauber" halten. Außerdem können Sie eine Rückgängig-Funktion erstellen. Außerdem können Sie Datum und Uhrzeit aufzeichnen und Benutzer, der die Aktion in der Spiegeltabelle ausgeführt hat (von unschätzbarem Wert in Situationen mit der Jagd nach Jagd).

Der andere Vorteil besteht darin, dass beim Abfragen des Primärdatenblocks keine versehentlich gelöschten Datensätze eingeschlossen werden können, es sei denn, Sie machen absichtlich Datensätze aus der Spiegeltabelle (möglicherweise möchten Sie Live-Datensätze 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 im Vergleich zum Löschen aus einer primären Tabelle, die Soft-Löschvorgänge verwendet, aber dennoch referenzielle Verbindungen zu anderen Tabellen aufweist, relativ einfach .

Welche weiteren Vorteile? - großartig, wenn mehrere Programmierer an dem Projekt arbeiten und Lesevorgänge in der Datenbank mit gemischten Fähigkeiten und Liebe zum Detail durchführen. Sie müssen nicht nachts aufbleiben und hoffen, dass einer von ihnen nicht vergessen hat, nicht gelöscht zu werden Datensätze (lol, Nicht einschließen gelöschte Datensätze = True), was beispielsweise dazu führt, dass die verfügbare Barposition der Kunden überschätzt wird, mit der sie dann Aktien kaufen (dh wie in einem Handelssystem), wenn Sie mit Handelssystemen arbeiten wird sehr schnell herausfinden, welchen Wert robuste Lösungen haben, auch wenn der anfängliche "Overhead" etwas größer ist.

Ausnahmen: - verwenden Sie als Richtlinie weiche Löschvorgänge für "Referenz" -Daten wie Benutzer, Kategorie usw. und "Hartlöschvorgänge" in eine Spiegeltabelle für "Fakt" -Daten, d. H. Transaktionsverlauf.

8
Code Warrior

Ich verwende normalerweise logische Löschungen - 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) und somit keine Auswirkungen auf die Leistung der Anwendung haben.

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 !

3
Galwegian

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

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

Ich denke in der Regel daran, Benutzer mehr zu löschen, als sie "auf unbestimmte Zeit" auszusetzen. Sie wissen nie, wann sie legitim zurückkehren müssen.

3
Jon Dewees

Re: "Ist das sicher?" - Das kommt darauf an, was du meinst.

Wenn Sie das mit physischem Löschen meinen, werden Sie verhindern, dass jemals jemand die gelöschten Daten findet, dann ja, das ist mehr oder weniger wahr; Sie können die vertraulichen Daten, die gelöscht werden müssen, sicherer physisch löschen, da dies bedeutet, dass sie dauerhaft aus der Datenbank gelöscht werden. (Beachten Sie jedoch, dass möglicherweise andere Kopien der fraglichen Daten vorhanden sind, z. B. eine Sicherungskopie oder ein Transaktionsprotokoll oder eine aufgezeichnete Version, die gerade übertragen wird, z. B. ein Paket-Sniffer. Nur weil Sie Daten aus Ihrer Datenbank löschen, ist dies nicht der Fall Ich garantiere, es wurde nicht woanders gespeichert.)

Wenn Sie meinen, dass durch das logische Löschen Ihre Daten sicherer sind, weil Sie werden nie irgendwelche Daten verlieren, das ist auch wahr. Dies ist gut für Prüfszenarien. Ich tendiere dazu, dies so zu gestalten, weil es die grundlegende Tatsache einräumt, dass einmal erzeugte Daten niemals wirklich verloren gehen werden (insbesondere wenn sie jemals das hatten) die Fähigkeit, beispielsweise von einer Internet-Suchmaschine zwischengespeichert zu werden). Natürlich erfordert ein reales Prüfszenario, dass nicht nur Löschvorgänge logisch sind, sondern auch Aktualisierungen zusammen mit dem Zeitpunkt der Änderung und dem Akteur, der die Änderung vorgenommen hat, protokolliert werden.

Wenn Sie damit meinen, dass die Daten nicht in die Hände von Personen gelangen, 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.

3
Ian Varley

Ich lösche mich fast immer und hier sind meine 2 Cent:

  • 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
  • isdeleted überall zu suchen ist kein Problem, Sie müssen userid trotzdem überprüfen (wenn die Datenbank Daten von mehreren Benutzern enthält). Sie können die Prüfung durch Code erzwingen, indem Sie diese beiden Prüfungen auf eine separate Funktion setzen (oder Ansichten verwenden).
  • anmutiges Löschen Benutzer oder Prozesse, die sich mit gelöschten Inhalten beschäftigen, werden sie solange "sehen", bis sie die nächste Aktualisierung durchführen. Dies ist eine sehr wünschenswerte Funktion, wenn ein Prozess Daten verarbeitet, die plötzlich gelöscht werden
  • synchronisierung: Wenn Sie einen Synchronisationsmechanismus zwischen einer Datenbank und mobilen Apps entwerfen müssen, werden Soft-Löschungen weniger schmerzhaft sein. Grundsätzlich vermeiden Sie Synchronisationsparadoxen, indem Sie das Problem von einem verrückten ADD/UPDATE/DELETE zu einem einfacheren ADD/UPDATE verschieben
3

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

Zuallererst muss bei Abfragen jede Abfrage das IsDeleted-Feld berücksichtigen, und bei komplexen Abfragen wird die Möglichkeit eines Fehlers größer.

Zweitens die Leistung: Stellen Sie sich eine Tabelle mit 100000 recs vor, bei der nur 3 aktiv sind, multiplizieren Sie diese Zahl nun für die 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 der Verlauf der Datensätze. Es gibt jedoch andere Methoden, um dieses Ergebnis zu erzielen. Sie können zum Beispiel eine Protokolltabelle erstellen, in der Sie Informationen speichern können: TableName,OldValues,NewValues,Date,User,[..], wobei *Valuesvarchar sein kann und schreiben kann Details in diesem Formular fieldname : value; [..] oder speichern Sie die Informationen als xml

All dies kann über Code oder Trigger erreicht werden, aber Sie sind nur eine Tabelle ONE mit Ihrem gesamten Verlauf. Eine weitere Option besteht darin, festzustellen, ob das angegebene Datenbankmodul native Unterstützung für die Änderungsnachverfolgung bietet. In der SQL Server-Datenbank gibt es beispielsweise SQL Track Data Change.

3
Max

Logische Löschungen, wenn die referentielle Integrität schwer ist.

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

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

Auf der positiven Seite:

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

Es ist leicht zu erkennen, zu welchem ​​Zeitpunkt sich der Zustand befand.

2
pkario

Dies ist ziemlich normal, wenn Sie eine Historie von etwas aufbewahren 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 und Ihre Abfragen zu komplizieren, können Sie einfach Ansichten erstellen, die die Filterung für Sie übernehmen, und Abfragen dagegen verwenden. Dadurch wird verhindert, dass diese Datensätze in Berichtslösungen und dergleichen verloren gehen.

2
BQ.

Ich habe Soft-Delete gemacht, nur um alte Aufzeichnungen zu behalten. Mir wurde klar, dass die Nutzer nicht so oft alte Datensätze ansehen, wie ich dachte. Wenn Benutzer alte Datensätze anzeigen möchten, können sie sie nur aus der Archiv- oder Audit-Tabelle anzeigen, oder? Was ist der Vorteil von Soft-Delete? Es führt nur zu komplexeren Abfrageanweisungen usw.

Folgendes sind die Dinge, die ich implementiert habe, bevor ich mich dazu entschloss, nicht mehr weich zu löschen:

  1. audit einführen, um alle Aktivitäten aufzuzeichnen (Hinzufügen, Bearbeiten, Löschen). Stellen Sie sicher, dass kein mit der Prüfung verknüpfter Fremdschlüssel vorhanden ist, und stellen Sie sicher, dass diese Tabelle gesichert ist und niemand außer Administratoren gelöscht werden kann.

  2. ermitteln Sie, welche Tabellen als "Transaktions-Tabelle" betrachtet werden, was sehr wahrscheinlich ist, dass sie für lange Zeit aufbewahrt wird, und sehr wahrscheinlich, dass der Benutzer die früheren Datensätze oder Berichte anzeigen möchte. Zum Beispiel; Kauftransaktion. Diese Tabelle sollte nicht nur die ID der Master-Tabelle (z. B. dept-id), sondern auch die zusätzlichen Informationen wie den Namen als Referenz (z. B. dept-name) oder andere erforderliche Felder für die Berichterstellung enthalten. 

  3. Implementieren Sie den Datensatz "active/inactive" oder "enable/disable" oder "hide/show" der Master-Tabelle. Anstatt den Datensatz zu löschen, kann der Benutzer den Master-Datensatz deaktivieren oder inaktivieren. Auf diese Weise ist es viel sicherer.

Nur meine zwei Cent Meinung.

2
David

Neben dem Systemdesign gibt es Anforderungen, die beantwortet werden müssen. Was ist die gesetzliche oder gesetzliche Anforderung an die Aufbewahrung von Aufzeichnungen? Je nachdem, 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 es erforderlich 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.

2
Dave

Um auf Tohid's Kommentar zu antworten, hatten wir das gleiche Problem, dass wir die Historie der Aufzeichnungen beibehalten wollten und auch nicht sicher waren, ob wir die is_deleted-Spalte haben wollten oder nicht.

Ich spreche von unserer Python-Implementierung und einem ähnlichen Anwendungsfall, den wir getroffen haben.

Wir haben auf https://github.com/kvesteri/sqlalchemy-continuum gestoßen, was eine einfache Möglichkeit ist, Versionierungstabelle für Ihre entsprechende Tabelle zu erhalten. Minimale Codezeilen und Erfassen des Verlaufs für das Hinzufügen, Löschen und Aktualisieren.

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

Auf diese Weise brauchten wir keine is_deleted-Spalte und unsere Löschfunktion war ziemlich trivial. Auf diese Weise müssen wir auch nicht daran denken, is_deleted=False in einem unserer APIs zu markieren.

1
Lalit

Mobile Apps, die von der Synchronisierung abhängig sind, können die Verwendung eines logischen statt eines physischen Löschens erzwingen: Ein Server muss dem Client mitteilen können, dass ein Datensatz (als markiert) gelöscht wurde. Dies ist möglicherweise nicht möglich, wenn Datensätze physisch gelöscht wurden.

1
axd

Sie lassen die Datenbank nicht funktionieren, da sie beispielsweise die Kaskadenfunktionalität nutzlos machen sollte.

Bei einfachen Dingen wie Einfügungen verdoppelt sich der Code dahinter, wenn sie erneut eingefügt werden.

Sie können nicht einfach einfügen, stattdessen müssen Sie nach einer Existenz suchen und einfügen, wenn sie noch nicht existiert, oder das Löschkennzeichen aktualisieren, wenn dies auch der Fall ist, während alle anderen Spalten auf die neuen Werte aktualisiert werden. Dies wird als Aktualisierung des Datenbank-Transaktionsprotokolls betrachtet und nicht als neues Einfügen, das ungenaue Überwachungsprotokolle verursacht.

Sie verursachen Leistungsprobleme, da Tabellen mit redundanten Daten in Konflikt geraten. Es spielt mit Indexierung vor allem mit Einzigartigkeit.

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

1
Taqveem

Es ist 2018 und ein großer Nachteil von Soft Delete ist:

DSGVO-Konformität

Ihre Anwendung ist wahrscheinlich nicht GDPR-konform, wenn Sie alles löschen, was als persönliche Daten gilt. [ 1 ] [ 2 ]

Denken Sie auch daran, dass Sie sich an die DS-GVO halten müssen, auch wenn Ihr Unternehmen nicht in der EU ansässig ist. [ 3 ]

1
zypA13510

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

Wenn Sie beispielsweise von einem staatlich regulierten System sprechen (z. B. einem System eines pharmazeutischen Unternehmens, das als Teil des Qualitätssystems gilt und die FDA-Richtlinien für elektronische Aufzeichnungen befolgen muss), dann haben Sie es besser gemacht, keine harten Löschungen vorzunehmen! Ein Auditor der FDA kann alle Datensätze im System abfragen, die sich auf die Produktnummer ABC-123 beziehen, und alle Daten sollten besser verfügbar sein. Wenn Ihr Geschäftsprozessbesitzer sagt, dass das System 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 historische Daten erhalten bleiben.

Möglicherweise hat Ihr System und seine Daten jedoch einen Anwendungsfall, z. B. "Verfolgung des Wetters am Nordpol". Möglicherweise nehmen Sie Temperaturmessungen einmal pro Stunde vor, und am Ende des Tages bilden Sie einen Tagesdurchschnitt. Möglicherweise werden die stündlichen Daten nach der Aggregation nicht mehr verwendet, und Sie müssen die stündlichen Messwerte nach dem Erstellen des Aggregats hart löschen. (Dies ist ein erfundenes, triviales Beispiel.)

Der Punkt ist, es hängt alles vom Anwendungsfall des Systems und seiner Daten ab und nicht von einer rein technologischen Entscheidung.

0
HardCode

Soft Delete ist eine Programmiermethode, 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 fatal sein kann. Dies ist der Fall, wenn das weiche Löschen relevant wird. Bei einem Soft-Delete löscht der Benutzer die Daten nicht wirklich aus dem Datensatz, sondern wird als IsDeleted mit true markiert (Nach normaler Konvention).

In EF 6.x oder EF 7 wird Softdelete als Attribut hinzugefügt, aber wir müssen jetzt ein benutzerdefiniertes Attribut erstellen.

Ich empfehle SoftDelete nachdrücklich in einem Datenbankentwurf und es ist eine gute Konvention für die Programmierpraxis.

0
Sanu Antony

Gut! Wie jeder gesagt hat, hängt es von der Situation ab. 

Wenn Sie einen Index für eine Spalte wie UserName oder EmailID haben - und Sie nie erwarten, dass derselbe UserName oder EmailID erneut verwendet wird; Sie können mit einem sanften Löschen gehen.

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

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

SELECT * FROM Benutzer, bei denen UserID = 123456 und IsDeleted = 0 ist

Diese Abfrage hat keinen Einfluss auf die Leistung, da die Spalte "UserID" 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:

Für die Anmeldung auf allen Websites wird EmailID als eindeutige Identifikation verwendet. Wir wissen sehr gut, sobald eine EmailID auf einer Website wie Facebook oder G + verwendet wird, kann sie nicht von anderen Personen verwendet werden.

Es kommt ein Tag, an dem der Benutzer sein/ihr Profil von der Website löschen möchte. Wenn Sie jetzt ein logisches Löschen vornehmen, kann sich dieser Benutzer nicht mehr registrieren. Eine erneute Registrierung mit derselben EmailID bedeutet auch nicht, den gesamten Verlauf wiederherzustellen. Jeder weiß, Löschen bedeutet Löschen. In solchen Szenarien müssen wir physisch löschen. Um den gesamten Verlauf des Kontos zu erhalten, sollten Sie solche Datensätze jedoch immer entweder in Archivtabellen oder in gelöschten Tabellen archivieren.

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

Denken Sie auch daran, dass weiche/logische Löschungen Ihre Tabellengröße, also die Indexgröße, erhöhen.

0
Jiten

Als Alternative geben wir Benutzer an, die Remote-Geräte verwenden, die über MobiLink aktualisiert werden. Wenn wir Datensätze in der Server-Datenbank löschen, werden diese Datensätze in den Client-Datenbanken nie als gelöscht markiert. 

Also machen wir beides. Wir arbeiten mit unseren Kunden zusammen, um zu bestimmen, wie lange sie Daten wiederherstellen können. Zum Beispiel sind Kunden und Produkte im Allgemeinen so lange aktiv, bis unser Kunde sagt, dass sie gelöscht werden sollten. Die Verkaufshistorie wird jedoch nur 13 Monate gespeichert und anschließend automatisch gelöscht. Der Kunde möchte gelöschte Kunden und Produkte möglicherweise zwei Monate lang aufbewahren, während die Historie sechs Monate aufbewahrt wird.

Wir lassen also über Nacht ein Skript laufen, das die logisch gelöschten Dinge nach diesen Parametern markiert. Zwei/sechs Monate später wird alles, was heute logisch gelöscht wurde, hart gelöscht.

Es geht uns weniger um Datensicherheit, als um riesige Datenbanken auf einem Clientgerät mit begrenztem Speicher, beispielsweise einem Smartphone. Ein Kunde, der zwei Jahre lang 200 Produkte zweimal in der Woche bestellt, hat eine Geschichte von über 81.000 Exemplaren, von denen 75% dem Kunden egal ist, ob er das sieht. 

0
TychaBrahe

Softdeleting wird meistens verwendet, weil Sie einige Daten nicht preisgeben möchten. Sie müssen sie jedoch aus historischen Gründen aufbewahren die Geschichte der Verkaufstransaktion). Im Übrigen kopieren einige den Produktinformationswert in den Verkaufsvorgangdaten, anstatt sich auf das Produkt zu beziehen, um dies zu handhaben. 

Tatsächlich sieht es eher nach einer Umformulierung für eine sichtbare/verborgene oder aktive/inaktive Funktion aus. Weil das in der Geschäftswelt "Löschen" bedeutet. Ich möchte sagen, dass Terminatoren Menschen löschen können, aber der Boss feuert sie einfach.

Diese Vorgehensweise ist ziemlich verbreitet und wird aus vielen Gründen von vielen Anwendungen verwendet. Da dies nicht der einzige Weg ist, um dies zu erreichen, werden Sie Tausende von Leuten sagen, dass das großartig oder Bullshit ist, und beide haben ziemlich gute Argumente.

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

Es liegt an Ihnen, Ihre Anforderungen zu kennen.

0
Marco Guignard