MySQL Cross Join allgemeine Fragen

  • Hallo,

    ich weiß nun nicht, ob dieses das korrekte Forum ist, da es ja arum geht, Daten aus einer Datenbank zu lesen- mit PHP aus mySQL um genau zu sein.

    Mein Problem ist relativ schnell umschrieben und ich habe auch schon viel gegooglet, aber ich stehe hier auf der Leitung befürchte ich. Ich habe schon länger mit PHP und MySQL zu tun und bin daher kein Neuling, dem ihr erst noch die Grundlagen erklären müsstet.

    Nun zu meiner Frage:

    Ich habe 2 Tabellen. In der einen stehen Bild ID und andere Details zu hochgeladenen bildern wie der original-Name, datum etc. und in der anderen stehen nur BildID und UserID.

    Mein Vorhaben: Eine Übersicht der letzten Bilder zu erstellen. ich kann hier nicht einfach die Bildnamen verwenden, da die Bilder in Unterordnern sind, welche die UserID des Uploaders als Namen tragen.

    Ich müsste nun also aus der Tabelle mit den Bildnamen und ID´s eben diese auslesen, was ich antürlich mit Leichtigkeit schaffe- auch die Datumsgeschichte um die letzten 5 zu nehmen. Zusätzlich muss ich neben select bilder where time is... nun auch noch die ID tabelle auslesen- also in der tabelle die passende bildID suchen und die entsprechende UserID auswählen um den Bildpfad zu ermitteln.

    Folgendes habe ich bisher:

    Vorab möchte ich mich natürlich schon einmal bedanken. Bis später dann ;)

  • Ich persönlich präferiere JOINs, aus Gründen einer übersichtlicheren Strukturierung. Die Bedingungen für die Tabellenverknüpfungen haben nach meiner Auffassung nichts in der WHERE-Klausel verloren. Die WHERE-Klausel ist dazu da die Ergebnismenge einzuschränken.

    "Programming today is a race between software engineers
    striving to build bigger and better idiot-proof programs,
    and the universe trying to build bigger and better idiots.
    So far, the universe is winning."
    Rick Cook

  • "Programming today is a race between software engineers
    striving to build bigger and better idiot-proof programs,
    and the universe trying to build bigger and better idiots.
    So far, the universe is winning."
    Rick Cook

  • hmm-ok. Auch nicht wesentlich komplizierter. Ich denke, die Entscheidung, welche man nimmt, ist auch eher eine Geschmacksfrage, oder? Schliesslich gibt es keine Funktion, die ermöglicht wurde um nicht angewendet zu werden, oder liege ich jetzt daneben? Allerdings muss ich zugeben, dass diese Lösung auch schön übersichtlich ist.

  • Intern macht es von der Geschwindigkeit keinen wirklichen Unterschied. Ich habe allerdings in größeren Projekten häufiger mal JOINs über 5+ Tabellen, und da ist es ohne JOIN-Klausel sehr mühselig wenn man nach mehreren Wochen nochmal an so eine Abfrage ran muß um Anpassungen vorzunehmen. Daher verwende ich prinzipiell nur noch JOINs.
    Mal abgesehen davon, dass das Beispiel von threadi nur eine Alternative für INNER JOINs bietet, nicht für OUTER JOINs.

    "Programming today is a race between software engineers
    striving to build bigger and better idiot-proof programs,
    and the universe trying to build bigger and better idiots.
    So far, the universe is winning."
    Rick Cook

  • ok, das ist wahr- aber da bei mir ja wirklich nicht sehr viel abgefragt werden muss und es ja auch nur inner ist, war seine antwort ja schon passend. bei den größeren sachen ist es völlig klar- wenn man es da auf die erste weise versucht, muss man schon nen eidetisches gedächniss haben

  • Ja klar, das wollte ich auch nicht bestreiten. Sein Beispiel funktioniert für deinen Fall genauso einwandfrei und ich kenne einige Leute denen diese Schreibweise besser gefällt.
    Ich bevorzuge für mich persönlich halt einfach aus Prinzip JOINs ;)

    "Programming today is a race between software engineers
    striving to build bigger and better idiot-proof programs,
    and the universe trying to build bigger and better idiots.
    So far, the universe is winning."
    Rick Cook

  • JOINs haben den Nachteil, dass sie innerhalb der Datenbank-Engine mehr Abfragen erzeugen. Führe mal ein Explain und Miss die Zeit für ein Statement mit JOIN aus und mach das selbe nochmal mit WHERE. Ich habe die Erfahrung gemacht, dass man auf JOIN besser verzichten sollte. Die Geschwindigkeit, gerade bei großen Datenbanken, kann dadurch noch gesteigert werden. Die Übersichtlichkeit kann man dagegen mit einer ordentlichen Einrückung und Zeilenumbrüchen einfach erreichen.

  • EXPLAINs bringen bei beiden Abfragen ein identisches Ergebnis.

    Zeitmessung:


    5 Beispieldurchläufe:

    "Programming today is a race between software engineers
    striving to build bigger and better idiot-proof programs,
    and the universe trying to build bigger and better idiots.
    So far, the universe is winning."
    Rick Cook

  • Das waren nur wenige Test-Datensätze, 20 Bilder, 40 User. MySQL-Version kann ich dir grad nicht sagen, bin erst Sonntag wieder zuhause, dann kann ich mal nachschauen. Ich teste das nächste Woche auch nochmal auf unserem Produktiv-Server in der Firma, da kann ich auf Tabellen mit ein paar Millionen Datensätzen testen. Interessiert mich schon, da meines Wissens beide Versionen von MySQL intern identisch verarbeitet werden (EXPLAIN schmeißt wie gesagt bei beiden Abfragen auch das identische Ergebnis).
    Ich kann mir aber eigentlich nicht vorstellen, dass die Performance bei vielen Datensätzen auf einmal unverhältnismäßig auseinanderdriftet.
    Generell muss ich sagen, ich habe sehr lange auch bei jedem "Kleinscheiß" auf Performance geachtet und allen möglichen Kram getestet. Davon bin ich aber völlig abgekommen, ich halte mich mittlerweile an den Leitsatz, dass als erste ausschließlich darauf hin entwickelt wird die Testcases ans Laufen zu kriegen und den Code übersichtlich und wartbar zu halten. Von Beginn an auf Performance zu achten ist nach meinen Erfahrungen absolut kontraproduktiv und sorgt nur für unnötige Verzögerungen in der Entwicklung. Performance-Optimierungen stehen an wenn das System fertig ist und läuft, und sich dann eben Performance-Probleme zeigen. Und da liegen die Flaschenhälse dann i.d.R. in ganz anderen Bereichen, als solchen Kleinigkeiten. Vielleicht revidiere ich da meine Meinung bezüglich unseres Falles hier nochmal, sollten sich tatsächlich bei großen Datenmengen stark spürbare Divergenzen ergeben. Kann ich mir aber wie gesagt bei den bisherigen Ergebnissen nicht vorstellen und habe ich auch vorher noch nie gehört.
    Bezüglich der Übersichtlichkeit/Lesbarkeit: Klar, bei so einer simplen Abfrage wie hier ist das ziemlich latte, trotzdem präferiere ich auchda schon JOINs, weil da eben das zusammensteht, was auch logisch zusammengehört, und nicht zerstückelt und über die Abfrage verteilt wird.

    "Programming today is a race between software engineers
    striving to build bigger and better idiot-proof programs,
    and the universe trying to build bigger and better idiots.
    So far, the universe is winning."
    Rick Cook

  • Ich habe den Test jetzt nochmal auf einem anderen Server mit zwei anderen Tabellen durchgeführt. Erste Tabelle mit 5,5 Millionen Datensätzen, gejointe Tabelle mit knapp über 100.000 Datensätzen. Mysql-Version 5.1.49.
    Kein Geschwindigkeitsunterschied zwischen den beiden Abfragen.

    "Programming today is a race between software engineers
    striving to build bigger and better idiot-proof programs,
    and the universe trying to build bigger and better idiots.
    So far, the universe is winning."
    Rick Cook