Komplexe Abfrage

[jobo]

"..ich versteh den Sinn nicht.."


Gute Augen!

der Join "countries c, languages l.." ist schon sehr ungewöhnlich, Tendenz "sehr fragwürdig".
Aber woher kommt ".._lang=25" als Alternative?

Die Kernsprachtabelle mit Codierung zur Einschränkung reinzujoinen ist doch total okay.
Der 2. Vorschlag scheint mir auch nicht okay, da dort zwar 'inner join' steht, aber die Join Kriterien zwischen Country und Language unklar bleiben.

Es ist kein Fehler, die Einschränkung auf code "en" im WHERE zu machen (also nicht auf einem technischen Schlüssel), dafür ist es ja da, das WHERE. Das eine sind halt JOIN Kriterien, das andere eben Filter (WHERE).
(Wir wissen, dass die Trennung manchmal unscharf ist und es sich mischen kann und ein JOIN meist auch als Filter wirkt).

Es geht halt einerseits um korrekte Verknüpfung der Tabellen und andererseits um beliebige, benötigte Filterung des Join Ergebnis, also um eine Eingrenzung des Ergebnis.

[Jumpy]

Zitat von jobo:

Aber woher kommt ".._lang=25" als Alternative?

Die 25 hab ich mir nur ausgedacht. Ich meinte damit das, wenn es immer englisch ist, es Käse ist die language Tabelle dazu zu joinen nur um die language-id zu bekommen. In dem Fall guck ich die einmalig nach (25 wäre raumsgekommen) und verwende die halt.

Macht natürlich keinen Sinn, wenn der Ländercode dynamisch in meinem Programm durch einen anderen ersetzt werden könnte, dann muss ich das so machen wie Ghostwalker das macht. Mich störte dann nur die Mischung zw. alter und neuer Join Syntax, darum mein zweites Beispiel.

Zitat von jobo:

Die Kernsprachtabelle mit Codierung zur Einschränkung reinzujoinen ist doch total okay.
Der 2. Vorschlag scheint mir auch nicht okay, da dort zwar 'inner join' steht, aber die Join Kriterien zwischen Country und Language unklar bleiben.

Das ist es ja gerade, es gibt keine Join-Bedingung zw. country und language Tabelle. Deswegen wird zu jedem Eintrag in der country Tabelle jeder Eintrag in der language Tabelle hinzuge-joined und erst die where-Bedingung schränkt das nachher wieder ein. Dank der Optimizer in den Datenbanken ist das wahrscheinlich egal, aber in meiner Version wird halt nur der Datensatz mit language=en dazugejoined.