[FRAGE] MySQL: zwei Datensätze abwechselnd ausgeben

[j-l-n]

Folgendes vereinfachtes Szenario für einen Chat:
MySQL-Tabelle mit drei Spalten: "sender", "to", und "message"
Nun möchte ich alle Nachrichten zwischen User A und B in einem Verlauf darstellen - also seine eigenen (select message from table where sender = :username) und die, die er erhalten hat (select message from table where to = :username).
Die Ausgabe soll aber logischerweise nicht so erfolgen, dass die einfach alle hintereinander folgen, sondern dass abwechselnd die Nachricht vom User A an B ausgegeben wird, und dann die Antwort zurück von B an A.

- - - Aktualisiert - - -

Moment, mir kommt eine Idee: man könnte doch jeweils den Timestamp mit auslesen, die zwei Abfragen dann in einem einzigen Objekt zusammenfügen, und dieses nach zeitlichen Verlauf ordnen und ausgeben. Wäre sinnvoll, oder?

 

[SteelWheel]

Hi Julian,

eigentlich ist Dein Query nur einer - nämlich (wie Du schreibst) mit "timestamp" und der Abhängigkeit "User A schrieb B" oder "User B schrieb A" (alle anderen sind unnötig). Die Sortierung kannst Du direkt auf dem Server machen - bei der Ausgabe achtest Du nur drauf, ob es einen Userwechsel beim Dialog gab (bspw. für die Darstellung "links" oder "rechts" [bei Sprechblasen]).

Mit "Userwechsel" meine ich den Unterschied zwischen "Monolog" oder doch "Dialog".

Beste Grüße




EDIT: Solltest Du dennoch unbedingt mit zwei Queries arbeiten, wäre der timestamp immer noch wichtig, DESC-Sort und vor Ausgabe das Reinfüttern in ein Array, wobei der timestamp den Key darstellt. Ist der Key schon präsent (zeitgleich abgeschickt o. ä.), legst Du eine Reihenfolge fest, wer wem zuerst vermeintlich geschrieben hat (indem die Message per [] an den Key gehängt wird; first come, first serve).

$messages[ timestamp ] = array(); // als Beispiel

 

[j-l-n]

bei der Ausgabe achtest Du nur drauf, ob es einen Userwechsel beim Dialog gab (bspw. für die Darstellung "links" oder "rechts" [bei Sprechblasen]).

Mit "Userwechsel" meine ich den Unterschied zwischen "Monolog" oder doch "Dialog".

Ja, das mache ich einfach über zwei verschiedene CSS-Klassen, die je nachdem verteilt werden.
Alles klar, danke für deine Infos!

 

[kkapsner]

Machst du es jetzt mit einem Query oder mit zwei? Denn zwei machen das Problem wirklich viel komplizierter, als nötig:

SELET `message`
	FROM `table`
	WHERE
		(
			`sender` = :username1 AND
			`to` = :username2
		) OR
		(
			`sender` = :username2 AND
			`to` = :username1
		)
	ORDER BY `timestamp` ASC

 

[j-l-n]

Danke dir, Korbinian. Übrigens gute Idee, das mit der Einrückung. Habe MySQL-Queries bisher noch nicht in der Form geschrieben.
Was anderes noch: wie ist denn das nochmal mit den Anführungszeichen in MySQL? Da gab es meines Wissens einen Unterschied zwischen doppelten und einfachen Anführungszeichen bei Strings und Hochkommata - bin da aber nicht mehr so fit drin...

 

[kkapsner]

Übrigens gute Idee, das mit der Einrückung.

Mache das bei größeren Statements immer so - erhöht die Lesbarkeit dramatisch.

wie ist denn das nochmal mit den Anführungszeichen in MySQL?

php - When to use single quotes, double quotes, and backticks? - Stack Overflow

 

[j-l-n]

php - When to use single quotes, double quotes, and backticks? - Stack Overflow

Alles klar, danke dir! Dann war's so, wie ich noch im Gedächtnis hatte.

 

[kkapsner]

Bitte.

 

[SteelWheel]

Da muss ich etwas widersprechen ... nämlich bei den Backticks: Immer dann, wenn Du mit MySQL arbeitest und absehbar ist, dass dies auch so bleibt, benutze diese! Diese Backticks beschleunigen den "Parser" und nehmen ihm Arbeit ab - denn es wird eben nicht vorab nochmals geprüft, ob es ein "reserved keyword" ist oder nicht ("insert into foo"/"insert into `foo`").

Bei dem Beispiel für "Variable interpolation" habe ich die Hände über dem Kopf zusammen geschlagen ... aber nicht vor Freude.

Einrückung von MySQL-Code: immer! Lesbar- und Wartbarkeit sind hier ganz oben - oder das schlichte Erkennen, wie der Query sich zusammensetzt (gerade bei mehreren Joins ein klares Muss). Und auch wegen Lesbarkeit - daher der Bogen zu dem Händeübermkopfschlagen -: Dein Editor macht es farbig - also setze verwendete Variablen auch als Stringkonkatenation nach außen. Das hilft nochmal zusätzlich für die Lesbarkeit - Deine, wohlgemerkt.

Kleines, fiktives Beispiel, wie es hier durchweg aussieht (kein Anspruch auf "perfekt"):

$update = "UPDATE 
	`foo_hat_einen_langen_namen`
SET 
	`c1`='" . $value . "',
	[...]
WHERE	`c1`='bar' 
LIMIT 1;";

Übrigens: Wenn Du Zahlen mittels Single-Quotes in die DB bringst, gibt es keinen Fehler - das funktioniert auch. Aber so kannst Du zumindest String/Zahl voneinander unterscheiden, wenn Du es bei Zahlen weglässt (musst nicht permanent eine Struktur vor Augen haben).

Bitte nicht wieder hauen ... denn: FINAAAAAAAAAAAAAAAAALEEEEEEEEEE!

 

[kkapsner]

Bei dem Beispiel für "Variable interpolation" habe ich die Hände über dem Kopf zusammen geschlagen

Aber da steht doch direkt auch

(It is recommended to use an API supporting prepared statements instead, as protection against SQL injection)

Finde den Abschnitt nicht so schlimm.

Dein Editor macht es farbig

Mein Editor macht auch Variablen, die interpoliert werden, farbig. Eventuell solltest du dir einen neuen Editor zulegen...

 

[SteelWheel]

Da hast Du mich erneut falsch verstanden - es ging mir nicht um "prep. states", sondern einzig um das Beispiel und wie es dort steht (nämlich "geschrieben"; schon seit 2012):

$query = "INSERT INTO `$table` (`id`, `col1`, `col2`, `date`) VALUES (NULL, '$val1', '$val2', '$date')";

Abgesehen davon, dass diese Schreibweise für einen INSERT als Beispiel "Entwickler-unfreundlich" ist, darf es für meinen Geschmack - liegt am Editor - eher so aussehen (Lesbarkeit!; nicht für den Moment beim Schreiben, sondern eben "später"):

$query = "INSERT INTO `" . $table . "` (`id`, `col1`, `col2`, `date`) VALUES (NULL, '" . $val1 . "', '" . $val2 . "', '" . $date . "')";

Um anzuknüpfen an Formatierungen, wäre das sogar die Top-Art-und-Weise:

$query = "INSERT INTO 
	`" . $table . "` 
SET 
	`id`=NULL,
	`col1`='" . $val1 . "',
	`col2`='" . $val2 . "',
	`date`='" . $date . "';";

Doch bevor Du mir jetzt was "anhängst": Ich gehe davon aus, dass die platzierten Variablen bereits "verarbeitet" sind. An alle PHP-Einsteiger: Warnung! ^^

Und der Editor: Notepad++ ... der macht mir aus diesem Beispiel schlichtweg einen String - Variablen in Queries lassen sich da nicht "mal eben" erkennen. Vielleicht siehst Du es als Schwäche, doch mit zwei anderen Editoren (bspw. Eclipse) konnte ich mich gar nicht anfreunden (mit div. Laufzeitbedingungen davon noch weniger). Vielleicht wäre es für Interpolation auch einfach nur eine Einstellungssache ... was mich übrigens gerade zu einer Lösung führt, die im Firebug-Thread für Erheiterung sorgt.

Beste Grüße aber auf jeden Fall.

 

[kkapsner]

Tut mir leid, ich verstehe nicht, was du uns sagen willst. Wie du siehst, wird hier im Forum die interpolierte Variable auch farbig markiert. In N++ ist das auch so (gut - standardmäßig ist das nur fett, aber das kann man ja einstellen).

Dein letzter Code ist schon lesbarer als die Vorherigen, aber mehr durch die Einrückung/Zeilenumbrüche als durch das fehlende Interpolieren... und so würde ich das nie schreiben - SQL-Injektion und so...

Beste Grüße aber auf jeden Fall.

Dir auch.

 

[miniA4kuser]

...und so würde ich das nie schreiben - SQL-Injektion und so...

Und wie würdest du das schreiben uim SQL-Injection zu vermeiden?

 

[SteelWheel]

und so würde ich das nie schreiben - SQL-Injektion und so...

Doch bevor Du mir jetzt was "anhängst": Ich gehe davon aus, dass die platzierten Variablen bereits "verarbeitet" sind. An alle PHP-Einsteiger: Warnung! ^^

Berechenbar, oder? Mir war das klar, dass sowas kommen würde ... aber das Beispiel kommt von Deiner verlinkten Seite und ist nur als Muster aufgegriffen. Es ist schön, dass wir (!) das nicht so schreiben ...

N++ nennt es "STRING VARIABLE" - falls es wer sucht für die "Interpolation". Zu finden unter: EINSTELLUNGEN -> STILE -> "php" -> "STRING VARIABLE"

Was mein Posting soll? Es ging um Formatierungen, warum lange INSERTs mistig sind, Empfehlung für Lesbarkeit, spätere Wartung und wie man es in der "Realität" vorfindet (das schließt auch gern mal 'ne SQL-Injection mit ein ). Du kannst es für Dich jetzt auch gern "best practise"-Empfehlung nennen - aber: ich rede nur von der Formatierung!

Aktuell frage ich mich aber ernsthaft, warum ich noch poste ...

 

[kkapsner]

@miniA4kuser: entweder mit prepared Statements oder mit dem PDO::quote() direkt beim zusammenbauen. Dann sieht man sofort, dass das richtig maskiert wurde.

Berechenbar, oder?

Natürlich

Aber ich hab' auch jetzt erst verstanden, was du mit

"verarbeitet"

genau gemeint hast.

aber das Beispiel kommt von Deiner verlinkten Seite

War eigentlich auch nicht als "best practice" Beispiel gemeint, sondern einfach nur um den Unterschied zwischen ", ' und ` zu klären.

aber: ich rede nur von der Formatierung!

OK, jetzt verstehe ich, was du sagen wolltest.
Und - ich mag' Interpolation auch nicht.

Aktuell frage ich mich aber ernsthaft, warum ich noch poste ...

Vielleicht ist dir langweilig?