PHP/MySQL - Random-Datenwert gleichzeit lesen und löschen

[Hayabusa274]

Hallo,
ich will einen Random-Datenwert aus meiner MySQL-Tabelle auslesen mit PHP. Jedoch will ich diesen ausgelesenen Wert danach sofort löschen. Wie kann man das tun?
Meine Tabelle besteht aus den Spalten
id (id, int, 10, unsigned, not null, , auto_increment, primary, ,) und
key (deren datenwerte ich zufällig auslesen will).
Dies hier ist mein Auslese-Befehl:

$abfrage = SELECT key FROM tabelle ORDER BY RAND(NOW()) LIMIT 1

Da ich ein Programmieranfänger bin, fällt mir diese abstrakte Denken innerhalb von Programmiersprachen noch einwenig schwer. Deswegen wäre ich euch dankbar wenn ich mir weiterhelfen könntet!

[P7BB]

Ich denke, du gehst da ein wenig falsch vor, wenn du Keys aus einer Datenbank auslesen willst. Ich würde einfach den ersten Datensatz abrufen, der verfügbar ist und diesen dann löschen, aber nicht über Zufalls-IDs oder sowas arbeiten, denn dort kann es ja gut vorkommen, dass diese ID schon gar nicht mehr existiert.

Edit: letzten Teil vom Post entfernt, ist vermutlich falsch!

[Rumple]

P7BBs Antwort versteh ich nicht, hier gibt es doch garkeine Zufalls-IDs.

Zurück zur Eingangsfrage:
Ich würde einfach "SELECT id, key FROM ..." machen, und dann mit einer zweiten DELETE-Abfrageden Datensatz mit der erhaltenen id löschen.

Das ist ersteinmal ziemlich einfach, sofern dein SQL-Server nur ein einzigen Client gleichzeitig hat. Ansonsten kann es passieren, daß zwei Clients denselben Datensatz bekommen.

[Hayabusa274]

Ja danke, das ist eine wirklich sehr gute alternative !
Dann werde ich mal meinen PHP-Skript umändern und mich hier melden wenn weitere Probleme auftauchen.

[P7BB]

P7BBs Antwort versteh ich nicht, hier gibt es doch garkeine Zufalls-IDs.

Jop, seh es grad auch, hab mich verlesen... :/

[Jodocus_]

Dir wäre schon viel eher geholfen, wenn du die Frage im richtigen Forum stellen würdest.

[Larius]

*hängt den Thread an den Traktor, nimmt n großen Schluck aus seiner Thermoskanne und schleift ihn in den richtigen Bereich*

PHP -> Webtechnik.

[Hayabusa274]

Das was Rumple anspricht macht mir einwenig sorgen.
Ich erläutere kurz mal mein Vorhaben, damit ihr vllt. einen geeigneten Lösungsweg besser/einfacher bestimmen könnt.

Ich habe ein kleines Spiel entwickelt für Android. Dies habe ich mit der Adobe AIR/Flash Entwicklungsumgebung umgesetzt. Damit sich zwei verschiedene Clients miteinander verbinden und spielen können, will ich den Adobe Cirrus Service nutzen. Wenn also ein Client seine Cirrus-ID bekommen hat, schickt er sie sofort zu meinem Server wo dann server-side die ID(key) in eine MySQL Datenbank eingetragen wird. Daraufhin soll das PHP-Skript eine zufällige ID(key) eines anderen Clients aus der Datenbank suchen und zu dem Client senden, damit er sich per RTMFP (Adobe P2P Service) verbinden kann. Vor der Verbindung soll die eigene ID(key) wieder aus der Datenbank entfernt werden, damit es nicht zu einer doppelt,mehrfach Verbindung kommt.

Ich hoffe ihr habt mein Vorhaben einigermaßen Verstanden. Und danke für die Hilfsbereitschaft!

[Kugelfisch23]

In deinem simplen Fall würde sich zur Vermeidung der Race Condition anbieten, nach dem (mutmasslichen) Löschen, d.h. nach dem Ausführen des DELETE-MySQL-Statements, mittels mysql_affected_rows() zu überprüfen, ob tatsächlich genau 1 Zeile gelöscht wurde. Wurde keine Zeile gelöscht (Rückgabewert 0), dann hat zwischen Lesen und Löschen bereits eine andere Instanz deines Skripts die fragliche Zeile gelöscht, den dadurch bezeichneten Client genutzt und du musst demnach eine neue Zeile wählen.

[accC]

Ich würde einfach "SELECT id, key FROM ..." machen, und dann mit einer zweiten DELETE-Abfrageden Datensatz mit der erhaltenen id löschen.

Das ist ersteinmal ziemlich einfach, sofern dein SQL-Server nur ein einzigen Client gleichzeitig hat. Ansonsten kann es passieren, daß zwei Clients denselben Datensatz bekommen.

Ja aber eigentlich keine so gute Idee. Wenn du standardmäßig 2 Abfragen machst, kann es tatsächlich sein, dass 2x der gleiche Eintrag geliefert wird und einmal gelöscht wird.

Fasst du aber das Auslesen und Löschen zusammen, wird es dieses Problem überhaupt nicht geben, da SQL (normalerweise) nur ganz-oder-garnicht kennt, Abfragen werden immer als "eins" betrachtet und erst komplett abgearbeitet, bevor eine andere Abfrage auf den gleichen Daten operieren darf..

Daher sollte das Auslesen und löschen innerhalb einer Abfrage getätigt werden.

Übrigens würde das über Views funktionieren.

Soetwas wie:

CREATE OR REPLACE VIEW anschauen AS (
SELECT * FROM tabelle WHERE schluessel = "wert"
AND
DELETE tabelle WHERE schluessel = "wert"
);

Dann fragst du nur den View ab.

Ungetestet und nur eine 0.5Minuten-Überlegung.

[Kugelfisch23]

Fasst du aber das Auslesen und Löschen zusammen, wird es dieses Problem überhaupt nicht geben, da SQL (normalerweise) nur ganz-oder-garnicht kennt, Abfragen werden immer als "eins" betrachtet und erst komplett abgearbeitet, bevor eine andere Abfrage auf den gleichen Daten operieren darf.

Das ist so nicht korrekt, das gilt nur für atomare Operationen, vgl. etwa http://dev.mysql.com/doc/refman/5.5/...nsactions.html. Dein genanntes View ist kaum atomar (da es aus zwei Operationen besteht), eine Race Condition wäre demnach möglich. Denkbar wäre bei komplexeren Veränderungen der DB der Weg über Transaktionen, allerdings wäre dazu eine transaktionale Storage-Engine wie z.B. InnoDB erforderlich. Deshalb in diesem simplen Fall mein Vorschlag, schlicht zu überprüfen, ob das DELETE-Statement erfolgreich war (diejenige Instanz, die den Datensatz per DELETE löscht, erhält ihn definitiv).

[accC]

Ah, ich verstehe was du meinst, ja, das ist natürlich auch eine Idee.
Allerdings hat der looser-Prozess dann eine weitere Abfrage zu tun, im ungünstigsten Fall mehrere (bis die Datenbank leer ist) .. Wäre ggf. auch nicht schön, oder?

Werden Views nicht als atomar behandelt? Ich sollte meine SQL Kenntnisse doch noch ein mal auffrischen.

[Kugelfisch23]

Allerdings hat der looser-Prozess dann eine weitere Abfrage zu tun, im ungünstigsten Fall mehrere (bis die Datenbank leer ist) .. Wäre ggf. auch nicht schön, oder?

Das ist korrekt, allerdings ist das meines Erachtens in diesem Fall nur ein geringes Problem. Schliesslich steigt zwar bei einem belasteten System die Gefahr der Kollisionen da mehr Instanzen des Skripts parallel laufen, allerdings steigt (da jeder Eintrag einen Client repräsentiert) auch die Anzahl der Einträge in der Datenbank, wodurch die Kollisionsgefahr wiederum reduziert wird. Dadurch wird die durchschnittliche Anzahl an benötigten Abfragen mit steigender Auslastung zumindest nicht stark ansteigen.

Man könnte sich natürlich fragen, ob eine relationale Datenbank für diesen Anwendungsfall überhaupt geeignet ist. Eine eigene Anwendung, welche die Clients im Speicher hält und auf Anfrage zufällig einen zurück liefert, wäre wesentlich performanter. Schliesslich müssen die Daten nicht einmal persistent gespeichert werden.