Hallo Joachim,
Wir schwant dunkel, das dieser Ansatz nicht optimal ist,
ist er meiner Meinung nach auch nicht. Er "funktioniert" wegen der Fehlertoleranz bzw. "Optimierung" von MySQL. Jedes andere DBMS, das ich kenne, gibt einen SQL-Fehler zurück. Ich finde das Verhalten der anderen DBMS gut.
denn wenn ich meine Quellen korrekt interpretiere, muss b jedesmal komplett gescannt werden um die Autorendaten aus b zu ermitteln. Ist es wie folgt besser gelöst (funktionieren tut es)?
Welche Quelle? Hast Du EXPLAIN verwendet?
[...] from
table\_a
as a LEFT JOIN
table\_b
as b ON
(a.article\_author\_id
=b.id
) LEFT JOIN
vorher hattest Du einen (impliziten) INNER JOIN, warum machst Du daraus einen OUTER JOIN?
FROM table_a a
INNER JOIN table_b b
ON a.article_author_id = b.id
gefiele mir besser. Jedem Beitrag ist ein existierender Autor zugeordnet => INNER JOIN. Nicht jeder Beitrag wurde bereits kommentiert => OUTER JOIN.
table\_c
as c ON
(a.id
=c.comment\_article\_id
)
where a.blog\_name
='blogname'
GROUP BY a.id
order by a.id
desc LIMIT 0, 10;Falls gut - weiter optimierbar?
Meiner persönlichen Meinung nach nicht gut. Es fehlt die Gruppierung nach folgenden Spalten:
a.article_title,
a.article_text,
a.article_author_id,
a.date
, -- Datentyp, hier ist das Quoten nötig
b.email,
b.nick
Zu Deinem Glück sind diese Daten alle direkt von a.id abhängig und somit für jeden Eintrag gleich, so dass MySQL nicht unvorhersagbare Daten zurückliefert. Ich halte von dieser "Optimierung" von GROUP BY durch MySQL nichts. Wenn man eine Aggregatsfunktion verwendet, so muss nach allen nicht aggregierten Spalten gruppiert werden - nach diesem strengen Grundsatz verfahren alle anderen mir bekannten DBMS. Weiterhin verzichte ich auf Spaltennamen wie "date", die eine spezielle Behandlung erfordern. [1]
Schau' Dir das Ergebnis von EXPLAIN an.
Freundliche Grüße
Vinzenz
[1] Backtickitis macht meiner Meinung nach SQL-Anweisungen in MySQL nicht lesbarer genausowenig wie Backslashitis PHP- oder Javascript-Statements.