Sollten wir jemals Daten in einer Datenbank löschen?

39

Ich bin neu in Datenbanken und versuche, die grundlegenden Konzepte zu verstehen. Ich habe gelernt, wie man Daten in einer Datenbank löscht. Aber einer meiner Freunde sagte mir, dass Sie niemals Daten in einer Datenbank löschen sollten. Wenn es nicht mehr benötigt wird, ist es besser, es einfach zu markieren oder als "nicht in Verwendung" zu kennzeichnen.

Ist das wahr? Wenn ja, wie würde ein großes Unternehmen wie IBM seine Daten hundert oder mehr Jahre lang verarbeiten?

Fuddin
quelle
2
Bitte klären Sie - fragen Sie, ob Sie Löschbefehle in SQL ausgeben sollen oder nicht, oder ob das zugrunde liegende Datenbankmodul tatsächlich Daten löscht, die als gelöscht markiert werden?
GroßmeisterB
4
@StartupCrazy: dieser Kommentar klärt nichts für mich.
Doc Brown
6
Wer ist mit "wir" gemeint?
Dynamische
3
Ich mag es sehr, alles fast besessen zu halten. Aber ich weiß nicht, in welchem ​​Geschäft Sie tätig sind, aber einige Daten müssen Sie gesetzlich für einen festgelegten Zeitraum aufbewahren, und einige Daten müssen Sie gesetzlich nach einem festgelegten Zeitraum löschen.
Pieter B
6
Hängt davon ab, um welche Art von Daten es sich handelt. In einigen Fällen müssen Sie es aus rechtlichen Gründen löschen.
CodesInChaos

Antworten:

63

Wie bei all diesen Dingen lautet die Antwort "es kommt darauf an".

Wenn der Benutzer die Daten wahrscheinlich wieder haben möchte, haben Ihre Freunde Recht - Sie löschen nicht wirklich, markieren Sie den Datensatz einfach als "gelöscht". Auf diese Weise können Sie die Daten wiederherstellen, wenn der Benutzer seine Meinung ändert.

Wenn die gelöschten Daten jedoch älter als ein bestimmter Zeitraum sind (z. B. ein Jahr), können Sie entscheiden, sie tatsächlich aus den Live-Tabellen zu löschen, sie jedoch entweder in einer Archivtabelle zu speichern oder nur zu sichern, falls der Benutzer dies wünscht es zurück. Auf diese Weise können Sie die Datenmenge (live und kürzlich gelöscht) auf ein Minimum beschränken.

Wenn die Daten jedoch kurzlebig sind oder leicht wiederhergestellt werden können, können Sie sich durchaus dafür entscheiden, die Daten tatsächlich zu löschen.

Es gibt eine Klasse von Daten , die Sie haben zu löschen - und das ist , personenbezogene Daten , dass der Benutzer möchte nicht , dass Sie nicht mehr halten. Möglicherweise gibt es lokale Gesetze (z. B. in der EU), die dies zu einer obligatorischen Anforderung machen (danke Gavin ).

Ebenso kann es Regeln geben, nach denen Sie verpflichtet sind, keine Daten zu löschen. Erkundigen Sie sich daher vor einer Entscheidung bei den Aufsichtsbehörden, was Sie tun müssen, um die gesetzlichen Bestimmungen einzuhalten.

ChrisF
quelle
8
In einigen Anwendungsbereichen (Buchhaltung, Medizinprodukte) ist es wahrscheinlich erforderlich, dass Daten aufgrund von Prüfungsanforderungen nicht gelöscht werden.
Paul
3
Unter bestimmten Umständen MÜSSEN Sie Daten löschen, beispielsweise Daten, die sich auf die persönlichen Daten eines Benutzers beziehen. Nach EU-Recht (und möglicherweise auch nach anderen Gesetzen) sollte ein Nutzer das Recht haben, die Entfernung seiner Daten zu verlangen. In diesem Fall müssen diese Daten gelöscht und nicht einfach als nicht mehr aktiv gekennzeichnet werden. Letzteres wäre eine Verletzung der Datenschutzgesetze.
Gavin Coates
Erhöht die Freigabe von Speicherplatz in der Datenbank die Leistung?
Viveksinghggits
17

Dies ist tatsächlich ein erhebliches Problem für viele Unternehmen. Es gibt keine Möglichkeit, genau zu bestimmen, welche Daten tatsächlich verwendet werden. Sie befinden sich also nur in der Datenbank. Das Löschen und Archivieren von Daten muss Teil jedes großen Systemdesigns sein, ist es aber selten. Die meisten Unternehmen leben nur damit, kaufen größere Datenträger und optimieren ihre Abfragen und Indizes, um die Leistung aufrechtzuerhalten, bis sie das System wechseln. Anschließend müssen sie erhebliche Anstrengungen unternehmen, um aktuelle Daten zu identifizieren und diese Datensätze dann nur auf ihr neues System zu migrieren.

Ja, Sie sollten Daten aus Ihrer Datenbank löschen, aber oft ist es nicht einfach zu sagen, was und wann.

TMN
quelle
1
"Es gibt keine Möglichkeit, genau zu bestimmen, welche Daten tatsächlich verwendet werden" - ich würde dem nicht zustimmen. Ein "IsDeleted" -Bitfeld in jeder Tabelle ist eine ziemlich saubere Methode, um einen Datensatz als nicht mehr relevant zu identifizieren. Die meisten Fragen, wie z. B. das Kaskadieren von Löschvorgängen, sind auch in physischen Löschschemata enthalten. Die Antworten hängen vom Datenmodell ab und davon, ob Sie mehr Wert auf Speichergröße oder Leistung legen.
KeithS
Das habe ich gesagt, Systeme müssen mit einer Art Ablaufanzeige ausgestattet sein. In Ermangelung dieser Indikatoren (was bei vielen Unternehmen der Fall ist) ist es nicht möglich zu ermitteln, welche Datensätze sicher gelöscht werden können.
TMN
12

Es gab bereits viele gute Antworten darauf, die sich so ziemlich auf "Abhängig von den Umständen" beschränken, und ich kann diesen nichts hinzufügen.

Eine Sache, die noch nicht erwähnt wurde, die meiner Meinung nach erwähnt werden muss, ist, dass Sie niemals Primärschlüssel wiederverwenden sollten, die von einer Sequenz oder einem AUTO_INCREMENT-System generiert wurden.

Wenn Sie ein Element löschen, dem von einem solchen System ein Primärschlüssel zugewiesen wurde, werden Lücken in der Primärschlüsselspalte durch die gelöschten Daten hinterlassen. Es besteht die große Versuchung, diese Lücken neuen Elementen zuzuweisen, wenn sie hinzugefügt werden, oder noch schlimmer, die vorhandenen Daten zu mischen, um eine neue ID zu erhalten, um die Lücken zu entfernen, aber dies führt zu Problemen, die Sie haben würden Sie müssen sich nie damit auseinandersetzen, wenn Sie die Schlüssel einfach in Ruhe gelassen haben.

Angenommen, Sie führen eine Datenbank mit Druckern für die Verwaltung der Nachbestellung von Verbrauchsmaterialien. Der Drucker 13, ein alter Laserdrucker, funktioniert nicht mehr, so dass Sie ihn wegwerfen können. In der Zwischenzeit bestellt jemand aus einem anderen Grund einen neuen Thermodrucker für den Barcode-Druck im Lager, und dieser Drucker kommt zufällig vor dem Ersatz für Drucker 13 an. Der Administrator meldet diesen neuen Drucker in der Datenbank an, da 13 jetzt kostenlos ist Wenn Sie IDs recyceln, wird dem neuen Thermodrucker 13 als ID zugewiesen.

Jetzt sagt Ihnen jemand, dass der Drucker 13 fast leer ist. Sie erinnern sich, dass der Drucker 13 ein Laserdrucker ist, sodass Sie ihn nicht in der Datenbank nachschlagen müssen und eine Tonerkartusche bestellen. Nur Sie mussten tatsächlich ein Thermotintenpaket bestellen, da der Drucker 13 kein Laserdrucker mehr ist. Wenn die Tonerpatrone eintrifft, können Sie sie nicht verwenden, da sie für den Drucker falsch ist. Sie können keine Barcodes mehr ausdrucken und keine Bestellungen versenden, die auf den Versand warten.

Schlimmer noch, was passiert, wenn Sie den Drucker 13 löschen und alle nach ihm kommenden Drucker mischen, um die Lücke zu füllen? Der Drucker 14 (eine altersschwache alte Punktmatrix) wird zum Drucker 13, der Drucker 15 wird zum Drucker 14 und so weiter.

Auf allen Druckern befinden sich Etiketten, sodass auf sie mit der Datenbank verwiesen werden kann. Jetzt sind jedoch alle Etiketten veraltet. Sie müssen sich umsehen, jeden Drucker im Unternehmen suchen (der Hunderte von Druckern enthalten könnte!) Und sie neu kennzeichnen. Das ist kaum eine effektive Nutzung der Zeit. Und es ist auch ein fehleranfälliger Prozess, und was passiert, wenn er einfach nie ausgeführt wird? Jemand ruft an, um mitzuteilen, dass der Drucker 14 defekt ist und dringend repariert werden muss. Sehen Sie also nach und stellen Sie fest, dass der Drucker 14 ein Tintenstrahldrucker an der Rezeption ist. Nur weil Sie die IDs gemischt haben, muss der Nadeldrucker dringend repariert werden. Der Typ, der das Problem angerufen hat, bleibt hängen, während die Rezeptionistin einen Techniker hat, den sie nie angerufen hat, um einen Drucker zu reparieren, der nicht kaputt war.

Sie sollten sich IDs, die von einem Auto-Inkrement-System zugewiesen wurden, als permanent vorstellen. Sie sind unveränderlich und können nicht wiederverwendet werden, selbst wenn das, worauf sich die ID bezieht, nicht mehr vorhanden ist. Einige Leute behaupten, dass sie sich keine Sorgen machen müssen, dass die IDs ausgehen, aber selbst bei 32-Bit-Systemen und signierten IDs sind immer noch etwa 2 Milliarden IDs verfügbar. Wenn Sie die ID-Spalte vorzeichenlos machen können, verdoppelt sich dies auf 4 Milliarden, und auf 64-Bit-Systemen ist die Anzahl der verfügbaren IDs buchstäblich größer als die Anzahl der Sterne am Himmel. Ihnen werden nicht die Ausweise ausgehen.

GordonM
quelle
3
In den meisten Fällen sollten Sie überhaupt nicht an automatisch generierte Zahlen denken, sie sind bedeutungslos und sollten dem Benutzer nicht zugänglich gemacht werden. Sie sollten niemals die Meldung erhalten, dass für Drucker 13 nur noch wenig Tinte zur Verfügung steht, möglicherweise "der Drucker in Suite 13", jedoch nicht die automatisch generierte Nummer.
Jmoreno
Richtig, aber das obige Beispiel war genau das, ein Beispiel, um zu veranschaulichen, was schief gehen kann, wenn Sie mit automatisch inkrementierten Schlüsseln herumspielen. In Wirklichkeit geht es eher um referentielle Integrität.
GordonM
Es ist nur ein RI-Problem, wenn Sie keine Fremdschlüsseleinschränkungen und stattdessen pseudo-Fremdschlüssel haben. In diesem Fall haben Sie wahrscheinlich größere Probleme.
Jmoreno
Sie wären überrascht, wie viele MySQL-Datenbanken, auf die ich noch stoße, genau so sind. Viele Entwickler scheinen eine Abneigung gegen Innodb zu haben und sogar diejenigen, die nicht alle seine Einrichtungen nutzen.
GordonM
4

Viele gute Antworten hier schon. Ich möchte nur eine Situation hinzufügen, die noch niemand erwähnt hat:

Sensible Daten . Wenn der Benutzer es löscht, dann löschen Sie es besser tatsächlich!

Eine sehr häufige Situation ist das Ändern / Zurücksetzen des Passworts. Sie möchten keine alten Passwörter (auch wenn sie gehasht, gesalzen usw. sind) in Ihrer Datenbank speichern. Benutzer verwenden möglicherweise ihre alten (und falschen) Kennwörter auf anderen Websites.

Auch wenn es um Gesetze geht, wie lange Sie bestimmte Arten von Daten speichern dürfen, ist das natürlich bei weichen Löschungen nicht der Fall. Sie müssen es tatsächlich löschen.

Also würde ich mich fragen: Wird der Benutzer (oder jemand anderes, zum Beispiel die Regierung) verrückt sein, wenn ich ihn glauben lasse, dass die Daten gelöscht wurden, aber tatsächlich habe ich sie immer noch und kann sie jederzeit wiederherstellen?

Jakob
quelle
Interessant. Implementieren die großen Unternehmen das wirklich?
Fuddin
2
Dies ist ein guter Punkt, aber in Bezug auf Ihr Kennwortverlaufsbeispiel - Sie möchten häufig alte Kennwörter speichern, um sicherzustellen, dass sie keine Duplikate der letzten 12 sind oder was auch immer. Verstehen Sie mich nicht falsch - ich mag diese Richtlinie nicht, aber ich habe sie implementiert und sie scheint in Unternehmensanwendungen ziemlich verbreitet zu sein.
Mike Partridge
2
Um pedantisch zu sein, sollten Sie niemals irgendwo ein Passwort speichern. Sie speichern das (in eine Richtung) verschlüsselte Ergebnis. Wenn jemand sein Passwort vergisst, generieren Sie ein neues für ihn. Es sollte KEINE MÖGLICHKEIT geben, ein Passwort "wiederherzustellen", denn wenn Sie es können, kann es auch jemand anderes.
TMN
1
Kreditkartennummern. Sollte niemals gelagert werden. MUSS eigentlich nie aufbewahrt werden. Wenn ein Kunde dumm genug ist, mir seine Kreditkartennummer per E-Mail zu senden, habe ich ein echtes Problem. Es muss Wege geben, es loszuwerden.
gnasher729
Die EU-DSGVO lässt grüßen.
Anzeigename
3

Ich entferne im Allgemeinen keine Benutzerdaten in meinen Datenbanken. Ich kennzeichne sie als versteckt. Allzu oft löscht ein Benutzer etwas aus Versehen und muss es einfach ersetzen. Es hilft auch, die referenzielle Integrität für verwandte Daten beizubehalten. Dies funktioniert für kleine bis mittelgroße Datenbanken. In Systemen, in denen die Leistung stark von dieser Entscheidung betroffen ist, wird dies auf besondere Weise behandelt, z. B. durch Archivierungstabellen, automatisierte Sicherungen usw.

Wir verwerfen Backend-Daten nach Bedarf, z. B. abgelaufene Website-Sitzungsdaten und alte Protokollinformationen. Es hat überhaupt keinen Sinn, sie für immer zu behalten.

Wie immer hängt die genaue Antwort jedoch von der jeweiligen Situation ab.

Matt S
quelle
1

Ich arbeite seit ein paar Jahren an einem Devisenantrag, bei dem dies auftauchte. Die Daten, die die Anwendung im Laufe der Jahre sammelte, wirkten sich auf die Leistung aus (sagen wir exponentiell).

Nachdem wir alles getan haben, was wir an Code konnten, schlugen wir dem Management vor, Daten zu archivieren, die älter als ein Jahr sind. Sie überprüften das Konzept (rechtliche Fragen) und zum Glück konnten wir es tun. Also haben wir gelöscht, aber auch die Daten archiviert, damit das Unternehmen weiterhin Berichte usw. erstellen kann.

dbalakirev
quelle
1

In den meisten Fällen sollten Sie die Daten für den Fall aufbewahren, dass sie in Zukunft benötigt werden. Das Unternehmen, für das Sie arbeiten, sollte sich die historischen Daten ansehen, um Entscheidungen zu treffen, die das Unternehmen in eine bestimmte Richtung lenken.

Sie sollten jeder Tabelle "Date_Time_Removed" -Spalten hinzufügen und dann anstelle des physischen Löschens der Zeile (n) ein Datum und eine Uhrzeit festlegen, zu der die Zeile virtuell gelöscht wurde. Dann würden Sie in Ihren gespeicherten Prozeduren oder SQL die Spalte 'Date_Time_Removed' berücksichtigen, z. B. blah aus table1 auswählen, wobei date_time_removed null ist

Natürlich sollten Zeilen, die versehentlich zu einer Datenbank hinzugefügt wurden, dauerhaft entfernt werden, insbesondere Testdaten.

Wenn Sie alle legitimen Daten behalten, können Sie Ihre Datenbank auch in Zukunft für die Lagerung verwenden.

Julian Mummery
quelle
0

Eine andere Situation als die anderen dargestellten ist, wenn Daten gelöscht werden, die Protokolle der in der Datenbank durchgeführten Vorgänge (einschließlich Löschung) jedoch für einen langen Zeitraum in Archiven gespeichert werden. Der Hauptumfang besteht darin, ein Rollback-System für frühere Daten zu implementieren. Es kann jedoch auch verwendet werden, um gelöschte Daten (die aus der Datenbank gelöscht, aber in Archiven gespeichert werden) auf irgendeine Weise zu speichern.

Das Speichern von Archiven mit gelöschten Daten wäre keine so große Sache. Große Unternehmen können auch Codeversionen und viele weitere Informationen speichern (um nicht über technisch relevante Dinge zu sprechen), so dass das Speichern großer Datenmengen für sie am Ende etwas Übliches ist.

Coral Doe
quelle