[Ben]

Morgen,
ziemlich blöder Titel, aber mir fiel nichts Besseres ein.

Ich habe zwei Tabellen. In der einen stehen Userdatensätze und in der anderen stehen Bilddatensätze.
Jeder User kann beliebig viele Bilder hochladen. Diese verwalte ich aktuell in einer separaten Tabelle, die über die UserID mit der User-Tabelle verbunden ist.

User-Tabelle: user_id, user_data
Bilder-Tabelle: image_id, user_id, image_filename


Ich steh nun gerade irgendwie auf dem Schlauch, was das Auslesen der Daten angeht.

PHP-Code:

$sql = "SELECT u.user_id, user_data, image_id, image_filename
FROM user AS u, images AS i
WHERE u.userid = ".$user_id."
AND u.user_id = i.user_id"; 


Das ist ja schlichtweg falsch.
Warum? Weil die Nutzerdaten nicht ausgelesen werden, wenn der Nutzer keine Bilder hochgeladen hat.

Ich wüsste jetzt gerade auch nicht, wie ich das mit einer Abfrage lösen könnte. Es ist nicht schlimm, wenn es zwei Abfragen sind, aber es wäre natürlich irgendwie netter, wenn ich es kompakt in einer Abfrage hätte .. allerdings nicht um jeden Preis.

Danke für die Hilfe.

[Flor1an]

Ui, dem Ben mal helfen zu können xD

Wie du schon gesagt hast ist bei dir das Problem dass ein Treffer nur kommt wenn ein User UND ein Bild existieren. Dafür musst du also das Bild optional machen.

Das kannst du mit einem LEFT JOIN lösen. RIGHT JOIN wäre dann den User optional machen, ist aber eigentlich das gleiche denn man könnte bei LEFT JOIN einfach die Reihenfolge tauschen.

Hier mal ein Beispiel wie es, ungetestet, funktionieren könnte:

SELECT u.user_id, user_data, image_id, image_filename
FROM user AS u
LEFT JOIN images AS i
ON (u.user_id = i.user_id)
WHERE u.user_id = $user_id

Sollte kein Bild existieren müssten image_id und image_filename einfach leer sein.

[Ben]

Das Schlimme an der Geschichte ist, dass ich gestern noch genau das an anderer Stelle verwendet habe. Bin anscheinend nicht wirklich fit im Kopf. Das passiert viel zu häufig ..

Nunja, klappt selbstverständlich wunderbar.
Herzlichsten Dank.

[Flor1an]

Hab mir schon gedacht dass du das eigentlich kennst ... aber man hat manchmal ein Brett vorm Kopf

[MrNiceGuy]

Leider ist diese Methode nicht immmter die Beste, da in diesem Falle ein einzelner Datensatz mit einer eventuell großen Menge Datensätzen verknüpft wird. Sprich: Stell dir vor ein User hat 100 Bilder, dann liest du auch 100 mal die Userdaten mit aus. OK, MySQL wird sehr wahrscheinlich so intelligent sein, dass das keine große Rolle spielt, aber im Bezug auf den Traffic zwischen MySQL und PHP ist das unter gewissen Umständen enorm!

Mir persönlich widerstrebt dieser Gedanke, weshalb ich in solchen Situationen eben doch auf mehrere Queries setze. Wäre allerdings mal interessant, welches - im bezug auf den Traffic - schneller ist, denn der Datenbank-Server ist nicht zwangsläufig immer der localhost...

[Ben]

In meinen Fall greift da vielleicht alle paar Tage mal (das ist schon viel) jemand drauf zu. Ich denke, dass das im Rahmen ist.

Trotzdem danke für den Hinweis, auch wenn ich den bereits im Kopf vermerkt hatte.

[Flor1an]

Bevor wir hier gleich wieder zwei Querys haben könnten wir doch die eine Abfrage noch filtern um den User nur einmal auszulesen.

SELECT u.user_id, user_data, image_id, image_filename
FROM user AS u
LEFT JOIN images AS i
ON (u.user_id = i.user_id)
WHERE u.user_id = $user_id
GROUP BY u.user_id

user_id sollte dann natürlich einzigartig sein.

[MrNiceGuy]

@Flo: Das ist nicht das, was ich meinte. Selbst wenn man 1 x den User ausliest (also nur den einen, den man haben will), bekommt man mit JEDEM Datensatz die selben Benutzerinformationen nochmal zurückgeliefert. Je nach Anwendungsfall ist das überaus unpraktisch, stelle man sich mal folgendes vor (bitte nicht vom Sinn ausgehen, das ist nur ein Extrem-Beispiel Jemand speichert ein Bild in einem BLOB-Feld und will zusätzlich zu den Infos des Bildes (und des Bildes selbst) alle Kommentare zu dem Bild auslesen. Würde er die Verknüpfung wie oben beschrieben durchführen, wäre in jeder Zeile, die zurückgeliefert wird das Bild aus dem BLOB-Feld enthalten. Das würde in diesem Beispiel zu einer enormen Datenmenge führen, die in dem Fall von MySQL an PHP übertragen werden muss!

[Flor1an]

Ich verstehe nicht ganz was du meinst. Ben möchte jeden User einmal auslesen und dazu wissen ob ein Bild existiert oder nicht. Mit meiner Abfrage wird jeder Benutzer genau einmal ausgelesen, falls es dazu ein Bild gibt wird dieses auch noch mit übergeben.

Bei meiner ersten Abfrage war der Fall das der User jedes mal ausgegeben wurde pro Bild dass er hat. Bei meiner zweiten ist das nicht mehr der Fall.

[Ben]

Ich glaube der Unterschied besteht in "zurückgegeben" und "ausgelesen".

[Flor1an]

Ich weiß nicht was MySQL intern macht aber zurückgeliefert wird bei mir zumindest nur höchstens ein Bild pro User! Und genau das war seine Kritik am Anfang!

[Ben]

Also mein Fall ist eigentlich, dass ich nur einen User habe, da ich ja auf die UserID abfrage und zu diesem User alle Bilder zusätzlich zu den Userdaten haben will.

[MrNiceGuy]

@Flo: ben schrieb, dass jeder User beliebig viele Bilder haben kann. Nehmen wir also einfach nur mal an, es gibt eine Tabelle user:

- uid
- name
- ...

und eine Tabelle bilder:

- uid
- user_uid
- ...

dann sieht eine Abfrage mit folgendem Aufbau:

SELECT * FROM `user` AS `u` LEFT JOIN `bilder` AS `b` ON `b`.`user_uid`=`u`.`uid` WHERE `u`.`uid`='1'

(im übrigen fast identisch mit dem Query aus deinem ersten Post!

Zitat von Flor1an

[...]

SELECT u.user_id, user_data, image_id, image_filename
FROM user AS u
LEFT JOIN images AS i
ON (u.user_id = i.user_id)
WHERE u.user_id = $user_id

) so aus:

  
uid  name  uid  user_uid  name  
1 "user 1" 1 1 "bild 1" 
1 "user 1" 2 1 "bild 2" 
1 "user 1" 3 1 "bild 3"

Und was ich meinte ist, dass bei derartigen Abfragen, bei der ein einzelner Datensatz mit einer beliebigen Menge Datensätze kombiniert wird, um keine 2 Abfragen machen zu müssen, je nach Datenbankstruktur "gefährlich" werden können, eben wenn z.B. große Datenmengen in der ersten Tabelle zu finden sind, die eigentlich nur ein Mal benötigt würden, in diesem Falle aber 3 Mal abgefragt würden. Es war jetzt nicht explizit auf die Problematik von Ben bezogen, sondern allgemein nur zum Bedenken in den Raum geworfen.

[Flor1an]

Darum habe ich meinen ersten Query doch überarbeitet! Ich habe genau verstanden was du meintest. Und deshalb hab ich doch noch einen Query geschrieben, der mit der GROUP BY Klausel denn dann wird "user 1" genau einmal ausgelesen! Vielleicht hast du das übersehen bei meinem zweiten Query!

[MrNiceGuy]

Aber das entsprach nicht dem, was Ben haben wollte *argh*

[Flor1an]

Ich bin, nachdem die erste Möglichkeit ja "falsch" war, davon ausgegangen dass er nur einen Eintrag auslesen möchte.

Aber wenn er zu einem User alle Bilder auslesen möchte dann wüsste ich nicht wie man dass realisieren sollte. Entweder mit 2 Querys einzeln, oder man liest eben die Userdaten zu jeden Bild dazu aus. Aber wie sollte es sonst aussehen?

[MrNiceGuy]

Ich weiß ja nicht, ob ich kein Deutsch schreibe, aber ich habe nie behauptet, dass es eine bessere Lösung gibt, ich wollte nur auf den oben beschriebenen Sachverhalt hinweisen, dass es eben in manchen Situationen besser ist lieber 2 Queries zu nutzen.

[Flor1an]

Damals dachte ich auch noch es geht darum NUR den User auszulesen und falls ein Bild existiert NUR ein Bild dazu auszulesen.

[JumperII]

Hallo,

MrNice meint, dass er eine Perfomance-Optimierung unter der Annahme, dass MySQL an dieser Stelle bzgl. einer internen Abfrageoptimierung suboptimal arbeitet, in PHP gemacht werden sollte. Sprich, es werden die 2 Tabellen für sich einmal ausgelesen und ein optimierter Algorythmus in PHP (oder in was auch immer) verwendet, um die Ausgabe zu realisieren.

Diese Form macht allerdings nur Sinn, wenn
- der SQL-Server und der Applikationsserver getrennte Server sind und ggf. die Netzwerkverbindung dazwischen etwas problematisch ist
- der SQL-Server den Anforderungen an den hinterlegten Daten nicht gerecht wird (sprich uterdimensioniert in Leistung und Kapazität)
- der Applikationsserver im Vergleich zum Datenbankserver extrem leistungsfähig ist
- der Algorythmus sehr speziell ist (nicht wie im vorliegenden Fall) und sich nicht oder negativ auf dem SQL-Server optimiert
- man gerne in der entsprechenden Applikationssprache arbeitet

M.E. dürfte im typischen Webhosting Bereich es keine Notwendigkeit geben hier eine spezielle Optimierung zu fahren, zumal damit eine Spezialisierung letztendlich erfolgt.
Das Thema wäre eines, wenn rießige Datenbestände auf einen (geclusterten) SQL-Server liegen und mehrere Applikationsserver (>> 5) darauf permanent in geringen Zeitabständen zugreifen bzw. entsprechende Zeitrestriktionen für einen Datenverarbeitungsdurchlauf vorliegen (z.B. HTTPS-Anfrage innerhalb 250ms mit einer Liste zu beantworten).

Gruß,
Jumper, the II.