Hello,
nein, das limit löscht erst einmal gar nichts. die erste abfrage dient nur dazu, den kleinsten timestamp der 30. größten timestamps zu bekommen. danach wird alles was kleiner ist gelöscht, sprich keiner der ersten 30. wird gelöscht, da diese alle größer sind.
Das bezog sich auch nicht auf Dein Select, sondern auf das limitierte DELETE. Das sorgt nämlich dafür, dass nur 30 Sätze gelöscht werden. Leider weiß man nicht welche, da es ja noch kein "Order by" bei "Delete" gibt.
Bei Deiner Methode ist nicht sichergestellt, dass nicht dopplete Timestamps vorhanden sind. Mal verkürt dargestellt:
lfdNr ID Timestamp
----- ----- ---------
1 44 333
2 43 333
3 42 333
4 40 295
5 36 250
6 35 249
7 34 249
8 33 249
9 31 248
10 30 200
11 29 200
Die Möglichkaeit ist in Systemen mit höherem Datenaufkommen sehr wahrscheinlich.
Nun sollen die neuesten 6 Sätze erhalten bleiben.
Nach deiner Methode würde dafür alles gelöscht werden, was einen Timestamp < 249 hat. Also bleiben die Sätze 1-8 übrig. Das sind aber 8.
Man kann sich unschwer vorstellen, dass es sich in Systemen mit hoher Dynamik und vielen gleichzeitigen Nutzern auch um mehr als 2 Sätze zuviel handeln könnte. Zum Glück wirkt sich der Fehler hier zur "sichern Seite" aus.
Als kleinen Beweis für das mehrfache Auftreten der Timestamps stelle ich Dir gerne auf Wunsch einen Auszug aus meinem Logbuch zur Verfügung. Sven Rautenberg hat bei einem Versuch, den er für mich gestartet hatte, im Mittel 135 Zugriffe pro Sekunde an das System abgesetzt und durchführen lassen.
Da man eine bessere Lösung mit ein wenig mehr Nachdenken programmieren kann, halte ich sie auch nicht für zu kompliziert. Faulheit führt immer zu schlechten Programmen.
Liebe Grüße aus http://www.braunschweig.de
Tom
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen