Wert aus der äußeren Query in der Sub-Subquery nutzen

[Lennynero]

Hi,
ich habe gerade ein Problem mit einer verschatelten Query:

SELECT
  a.id,
  a.name,
  b.b_id,
  b.preis,
  c.bezeichnung,
  (SELECT
     GROUP_CONCAT(b_inner.preis)
   FROM
     a_inner
   JOIN
     a_inner.id = b_inner.b_id
   JOIN
     (SELECT
        x.a_id
        x.bezeichnung
      FROM
        x
     WHERE 
        x.name = a.name) AS c_inner
    WHERE 
       a_inner.id = a.id) AS vergleich
FROM
  a
JOIN
  b
ON
  a.id = b.a_id
JOIN
  (SELECT
     a_id
      bezeichnung
   FROM
      x
  WHERE 
     wert = 1) AS c
  ON a.id = c.a_id

An der Stelle "x.name = a.name" habe ich das Problem, das MySQL dort die Spalte "a.name" nicht kennt (Unknown column 'a.name' in where clause).

Gibt es einen Trick wie ich da drankomme oder muss ich mir einen Umweg über die mittlere Query bauen?

[AmicaNoctis]

Hallo,

diese Abfrage ist einfach ungültig. Die Spaltenreferenzen sind nicht durch Komma getrennt, eine Unterabfrage als Spaltenreferenz ist auch irgendwie unsinnig. Das kann gar nicht funktionieren.

Gruß,

Amica

[Lennynero]

Sorry, habe die Kommatas einfach vergessen.

Und die Referenz ist ja nicht die Unterabfrage, sondern eine der Spalten aus der äußeren Abfrage sol Bezugspunkt für die Sub(sub)query sein.

Das funktioniert z.B. mit "a_inner.id = a.id" ja auch.

Ersetzte ich bei "x.name = a.name" z.B. "a.name" durch einen festen Wert, funktioniert es.

Unsinnig: die ursprüngliche Query ist noch etwas komplexer, beinhaltet aber genau die gleiche Logik.

Ich habe eine Abfrage und Suche zu dem Ergebnis passende Referenzwerte. Diese werden im Grunde genauso aufgebaut wie die Werte der eigentlichen Query und müssen dann eben noch einen Bezug zu der Zeile haben, in der sie abgefragt werden (was mit Subqueries ja auch super funktioniert). Klar, mit "GROUP_CONCAT" erhalte ich da ein übles Konstrukt, aber ich habe den Vorteil das ich die Abfrage in meiner Klasse anpasse und das Ergebnis relativ einfach ohne große weitere Logik ausgeben kann.

[AmicaNoctis]

Ich bin der Meinung, dass man das Problem auch mit ordentlichen Joins lösen kann (auch wenn ich es jetzt auf Anhieb und ohne die Bedeutung der einzelnen Spalten zu kennen nicht komplett nachvollziehen kann). Korrelierte Unterabfragen sind ein Performance-Problem und auch die Lesbarkeit ist bei deiner Verschachtelung im Eimer.

Versuch's mal mit den Joins.

[Lennynero]

Ich bin der Meinung, dass man das Problem auch mit ordentlichen Joins lösen kann (auch wenn ich es jetzt auf Anhieb und ohne die Bedeutung der einzelnen Spalten zu kennen nicht komplett nachvollziehen kann). Korrelierte Unterabfragen sind ein Performance-Problem und auch die Lesbarkeit ist bei deiner Verschachtelung im Eimer.

Versuch's mal mit den Joins.

Ich generiere eine Preisliste, die bestimmten Bedingungen unterliegt (die sind im Detail aber bei meinem Problem unwichtig).

Zu jedem Eintrag möchte ich aber noch angezeigt bekommen wenn für den gleichen Anbieter ähnliche Produkte aber mit anderem Preis vorliegen (die Bedingungen sind sonst die gleichen wie bei der äußeren Abfrage).

Das können NULL bis n verschiedene Produkte sein, weshalb ich mit GROUP_CONCAT (und im original nutze ich noch CONCAT um Produkt und Preis zusammenzusetzen) die entsprechenden Werte in ein Feld schreibe, das ich im (PHP)-Ausgabeskript auswerten kann.

Die gleiche Methode (in der diese Abfrage sitzt) wird aber noch an anderen Stellen genutzt, weshalb eine komplette Änderung der Abfrage nicht in Frage kommt.

Performance: in der Testumgebung brauchte das neue Skript knapp 150% der Zeit die das "Original"-Skript benötigt. Alternativ hätte ich auch beim durchlaufen des PHP Skriptes eine neue Methode aufrufen in der ich dann eine weitere Abfrage ausführen, was sich von der benötigten Zeit nicht viel gegeben hat.

Lesbarkeit: in meiner Entwicklungsumgebung ist das durchaus noch lesbar und im Grunde ist das doch auch nichts anderes wie eine drefache Verschachtelung.