Laravel - SQL Datensätze löschen?

1 Antwort

Vom Fragesteller als hilfreich ausgezeichnet

Eine Kombination aus 3) und 2) würde ich noch in Betracht ziehen: Im laufenden Betrieb das Flag deleted setzen (wobei ich da einen Timestamp (NULL=nicht gelöscht) nehmen würde, weil dann kann ich Datensätze, die vor mehr als X Tagen gelöscht wurden, ggfs. archivieren oder endgültig löschen). Dann in einem Cronjob irgendwann in der Nacht einmal täglich oder wie immer du willst die gelöschten Daten gesammelt umkopieren und aus der aktiven DB löschen. Je nach Datenbank dann ggfs. noch ein "optimize table" o.Ä. hinterherschicken.

Selbst der Fall 1) kann sinnvoll sein, z.B., wenn eh jede Nacht die gesamte DB noch einmal extern gesichert wird. Kommt halt auch darauf an, wie oft du damit rechnest, das versehentlich gelöscht wurde oder ob du aus anderen Gründen die Daten archivieren musst...

Woher ich das weiß:Berufserfahrung – Softwareentwickler & Admin

perhp 
Fragesteller
 19.08.2018, 21:16

Das mit dem deleted timestamp ist nicht einmal eine schlechte Idee. Somit kann ich mit dem Crawler alle 2 Wochen drübergehen und die Daten endgültig löschen. Bis dahin sollte jeder die Möglichkeit haben den Fehler rückgängig zu machen. Der Grund wieso ich die gelöschten Datensätze in eine eigene Tabelle verschieben wollte, lag darin, dass dann die Performance besser wäre, wenn es wirklich viele Datensätze in der Tabelle geben würde und diese gelöschten Einträge nicht mehr berücksichtigt werden müssten.

0
iQa1x  20.08.2018, 07:48
@perhp

Es ist halt die Frage, wieviele Datensätze du da erwartest. Wenn die Indexe passen, merkst du bei einer halben Million DS in einer Tabelle noch nicht wirklich eine Performanceeinbuße. Selbst mein Backup-Katalog mit >20Mio Datensätzen ist bedienbar, allerdings merkt man da Verzögerungen.

0
perhp 
Fragesteller
 20.08.2018, 10:51
@iQa1x

Was meinst du genau mit " wenn die Indexe passen"? Mit Millionen Datensätze rechne ich jetzt nicht, mit der Zeit könnte ich dann immer noch mal die alten Datensätze aufräumen

0
iQa1x  20.08.2018, 18:54
@perhp

Naja, das es für die Felder, die in WHERE Bedingungen bei den Abfragen oft vorkommen, passende, ggfs. auch zusammengesetze Indexe (CREATE INDEX) gibt. Bei mysql/mariadb kann man mit EXPLAIN SELECT ... nachschauen, wie der eine Abfrage ausführt und da ggfs. optimieren. Wenn da irgendwas mit ALL oder FULL TABLESCAN rauskommt, ists halt langsam. Bei JOINs kann manchmal auch die Umstellung der Reihenfolge eine Abfrage beschleunigen. Da zusätzliche Indexe zwar Abfragen beschleunigen, aber Updates/Inserts langsamer machen, macht es aber keinen Sinn, für Alles einen Index zu erzeugen.

0