Feste Menge an Einträgen immer aktualisieren

[norodon]

Hiho,

ich gebe zu, der Titel verwirrt sicher ein wenig jedoch fiel mir kein besserer ein.

Ich habe folgendes Problem, oftmals habe ich den Fall, dass ich eine feste Anzahl an Einträge in einer DB haben will: z.b. die leztem 30 Suchanfragen oder die letzten 10 Referer Links.

Jetzt wären meine beiden Ideen folgende:
Entweder immer wieder hinzufügen eines Beitrags und löschen des ältesten oder: aktualisierung des ältesten Beitrags mit dem neusten Inhalt.

Sprich ersetzen oder neuanlegen jedesmal.

Was wäre Performanter? Wie wäre das Problem elegant zu lösen?

p.s: war mir nicht sicher ob MySQL oder PHP Sektion, da ich auch eine Implementierung suche, betrifft es ja beides

Grüße
Noro

[pekka]

Entweder immer wieder hinzufügen eines Beitrags und löschen des ältesten oder: aktualisierung des ältesten Beitrags mit dem neusten Inhalt.

Sprich ersetzen oder neuanlegen jedesmal.

Na ersteres natürlich.

[norodon]

Finde ich z.B. unerwartet. Das Löschen und Neueintragen geht schneller als das Aktualisieren eines Datenbankeintrags?

[onemorenerd]

Erzähle mal etwas über DB-Struktur, Storage Engine, Zugriffsverteilung und deine Anforderungen. Bei weniger ist 1k Datensätzen ist es die Sache nämlich nicht wert, alle Möglichkeiten aufzudröseln. Es läuft ohnehin darauf hinaus, dass der Unterschied kaum messbar sein wird.

[MyHoPa.de]

Neu anlegen, alle anderen Löschen

Am einfachsten machst Du erst ein "INSERT INTO [..]" Query und dann ein "DELETE FROM [..] WHERE id>".(mysql_insert_id()+9);

Hierbei geh ich natürlich davon aus, dass Du eine id-Spalte mit Auto-Increment hast.

Händische updates von einzelnen Datensätzen sind kompliziert und können komisches Verhalten bei gleichzeitigen Zugriffen hervorrufen.

PS:
Solange Du nicht für Heise den Newsticker programmierst mach Dir mal eher um das PHP was Du benutzt n Kopf als um die Datenbank

[TobiaZ]

Hierbei geh ich natürlich davon aus, dass Du eine id-Spalte mit Auto-Increment hast.

Und davon, dass die Nummerierung rückwärts erfolgt!

Abgesehen davon, darf nicht aus irgend einem Grund eine Zeile manuell gelöscht werden.

Prinzipiell würde ich die Lösch-Logik aus der Applikation entfernen und über eine z.B. täglichen Cronjob steuern. Ein SELECT der letzten 30 Datensätze aus 100, 1.000, oder 10.000 Einträgen sollte ja kein Problem für die Performance darstellen.

Händische updates von einzelnen Datensätzen sind kompliziert und können komisches Verhalten bei gleichzeitigen Zugriffen hervorrufen.

Was genau meinst du damit?

[norodon]

Ok, also ich erhoffe mir später viele Zugriffe, zur Zeit kann ichs nicht abschätzen, aber es kommt mir auf performance an, weil ich schon größere Mengen an besuchern erwarte.

Ich sag einfach mal grob zwischen 10k am Tag evtl auch mehr.


Wie würdet ihr das Realisieren?

Meine Priorität liegt natürlich auf den letzten 30 Suchanfragen, der Referer wäre nur ne Spielerei.


Ich würde das Ganze auch gern damit verbinden, dass ich jede Suchanfrage speicher um später auch eine "Last-30-Searchs"-Cloud zu basteln.

Daher wäre ne Idee für ne DB :

id suchstring count lastsearched


Die letzten 30 Suchanfragen würde ich dann per Limit 30 rausbekommmen und eine "Search"-Cloud über die Count spalte.

Das würde zusätzlich auch das "Delete" Problem bei mehrfachzugriff erübrigen. Allerdings sind Suchanfragen schnell getippt und innerhalb kurzer Zeit wäre die Liste ins unermessliche gewachsen. Dort würde ich evtl mit nem täglichen Cron-Job den Table täglich oder stündlich löschen lassen.

Meinungen?

Lg Noro

[case]

Mit deiner letzen Idee kannst du dann auch nicht nur die 30 letzten sondern auch die 30 meißtgesuchten ausgeben lassen, was natürlich auch noch eine schöne Sache ist. Beim Updaten eines Eintrages würde ich das allerdings irgendwie mit einem SOUNDEX machen, um tippfehler etc. zum richtigen Suchergebnis zuzuordnen. Aber um ehrlich zu sein habe ich SOUNDEX noch nie benutzt und weiß nicht wie zuverlässig das ist

Original geschrieben von TobiaZ
Und davon, dass die Nummerierung rückwärts erfolgt!

Er hat sich doch nur verschrieben, er meinte doch Auto-Decrement^^

[MyHoPa.de]

Verzeihung, da hab ich mich wohl verschrieben

Aber für die einfach gestrickten unter uns nochmal richtig herum:

Ich würde:

Erst ein "INSERT [..]" Query absetzen und dann ein

"DELETE FROM [] WHERE id<".(mysql_insert_id()-9);

Falls man zwischendurch Einträge löschen möchte und jederzeit unabdringbar mindestens 10 Einträge vorhanden sein müssen, dann kann man übrigens auch "DELETE FROM [] WHERE id<".(mysql_insert_id()-19); draus machen.

Von der Chronjob-Lösung würd ich absehen, weil Du damit eine potenzielle Sicherheitslücke in Deine Applikation baust. Wenn jemand eine DOS-Attacke fährt, und zumindest bei erfolgreichen Seiten gibts sowas öfter mal, dann is nich nur Dein Server unten, sondern auch die Datenbank voll und im schlimmsten Fall der Server auf dem die DB läuft auch.

Zur Erklärung (um belustigte Nachfragen zu vermeiden):
Lässt jemand ein script auf Deinen Rechner los der Requests macht wie:
my_search.php?suchwort=0
my_search.php?suchwort=1
my_search.php?suchwort=2
my_search.php?suchwort=3
my_search.php?suchwort=4
[..]
my_search.php?suchwort=11111111111111111111111

Dann zwingt das im schlimmsten Fall nich nur die CPU in die Knie sondern legt auch jedesmal säuberlich einen Datensatz an.
Setzt Du also gleich danach den DELETE ab, dann kommt zwar auch der Server nichmehr hinterher, Du kannst aber danach weiter auf der DB arbeiten.

@TobiaZ: zu Änderungsanomalien würde ich Dich bitten doch hier:
http://de.wikipedia.org/wiki/Anomalie_(Informatik) mal nachzulesen. Ist ein leidiges Thema und äußert sich durch nicht reproduzierbare Fehler, die keinen Spass machen.