Komplexe Abfrage

[Ghostwalker]

Ich versuch grad ein SQL-Statement zusammen zu bauen, aber das will nicht:

Code:

SELECT c.country_id         AS countryId,
       c.country_shortcode  AS ISOShort,
       c.country_longcode   AS ISOLong,
       l.lang_id            AS LangId,
       cn.cn_name           AS countryName,
       rn.reg_name          AS regionName,
       sn.srn_name          AS subregionName
FROM countries c,
     languages l 
     LEFT JOIN country_names cn ON cn.cn_cid = c.country_id AND cn.cn_lang = l.lang_id,
     LEFT JOIN region_names  rn ON rn.reg_id = c.country_region AND rn.reg_lang = l.lang_id,
     LEFT JOIN subregion_names sn ON sn.sr_id = c.country_subregion AND sn.srn_lang = l.lang_id 
WHERE (l.lang_code = "en") 
ORDER BY c.country_id;

Die Tabellennamen passen, die Feldnamen passen auch. Aber bei der Ausführung in SQLiteStudio (und auch in anderen Tools) meckert er, das er die Tabelle LEFT nicht kennt.

Das sagt mir, das da irgendwo ein Fehler drinn ist. Aber ich erkenne auch nach 2 Std nix, was da falsch wäre.

Könnt ihr mir da mal auf die Sprünge helfen ?

[Ghostwalker]

Autsch

die Kommas bei den Joins weglassen, dann gehts !.

[Jumpy]

Ich versteh den Sinn des Inner Join mit "languages l" nicht.
Such dir die l.lang_id raus wo der l.lang_code='en' ist und pack das direkt deine Joinbedingungen:

SQL-Code:

SELECT c.country_id        AS countryId,
       c.country_shortcode AS ISOShort,
       c.country_longcode  AS ISOLong,
       25                  AS LangId,       --nur mal als Beispiel
       cn.cn_name          AS countryName,
       rn.reg_name         AS regionName,
       sn.srn_name         AS subregionName
FROM countries c
     LEFT JOIN country_names cn ON cn.cn_cid = c.country_id AND cn.cn_lang = 25,
     LEFT JOIN region_names rn ON rn.reg_id = c.country_region AND rn.reg_lang = 25,
     LEFT JOIN subregion_names sn ON sn.sr_id = c.country_subregion AND sn.srn_lang = 25
ORDER BY c.country_id;

oder wenn du das wirklich so flexibler halten willst könntest du den INNER JOIN auch tatsächlich wie in der neuen Syntax üblich verwenden:

SQL-Code:

SELECT c.country_id        AS countryId,
       c.country_shortcode AS ISOShort,
       c.country_longcode  AS ISOLong,
       l.lang_id           AS LangId,
       cn.cn_name          AS countryName,
       rn.reg_name         AS regionName,
       sn.srn_name         AS subregionName
FROM countries c
     INNER JOIN languages l on l.lang_code = "en"
     LEFT JOIN country_names cn ON cn.cn_cid = c.country_id AND cn.cn_lang = l.lang_id,
     LEFT JOIN region_names rn ON rn.reg_id = c.country_region AND rn.reg_lang = l.lang_id,
     LEFT JOIN subregion_names sn ON sn.sr_id = c.country_subregion AND sn.srn_lang = l.lang_id
ORDER BY c.country_id;

[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.

[Ghostwalker]

Zitat von Jumpy:

Ich versteh den Sinn des Inner Join mit "languages l" nicht.
Such dir die l.lang_id raus wo der l.lang_code='en' ist und pack das direkt deine Joinbedingungen:

SQL-Code:

SELECT c.country_id        AS countryId,
       c.country_shortcode AS ISOShort,
       c.country_longcode  AS ISOLong,
       25                  AS LangId,       --nur mal als Beispiel
       cn.cn_name          AS countryName,
       rn.reg_name         AS regionName,
       sn.srn_name         AS subregionName
FROM countries c
     LEFT JOIN country_names cn ON cn.cn_cid = c.country_id AND cn.cn_lang = 25,
     LEFT JOIN region_names rn ON rn.reg_id = c.country_region AND rn.reg_lang = 25,
     LEFT JOIN subregion_names sn ON sn.sr_id = c.country_subregion AND sn.srn_lang = 25
ORDER BY c.country_id;

oder wenn du das wirklich so flexibler halten willst könntest du den INNER JOIN auch tatsächlich wie in der neuen Syntax üblich verwenden:

SQL-Code:

SELECT c.country_id        AS countryId,
       c.country_shortcode AS ISOShort,
       c.country_longcode  AS ISOLong,
       l.lang_id           AS LangId,
       cn.cn_name          AS countryName,
       rn.reg_name         AS regionName,
       sn.srn_name         AS subregionName
FROM countries c
     INNER JOIN languages l on l.lang_code = "en"
     LEFT JOIN country_names cn ON cn.cn_cid = c.country_id AND cn.cn_lang = l.lang_id,
     LEFT JOIN region_names rn ON rn.reg_id = c.country_region AND rn.reg_lang = l.lang_id,
     LEFT JOIN subregion_names sn ON sn.sr_id = c.country_subregion AND sn.srn_lang = l.lang_id
ORDER BY c.country_id;

Da "en" ein Parameter ist, den ich hier nur zum testen fix gemacht hab, ist das 1. keine Option.

Den INNER JOIN hätte ich verwenden können, käme auf das gleiche raus. Welchen Vorteil hätte ich da ?

Da es keine Beziehung zwischen der Country-Tabelle und der Language-Tabelle gibt, erschien mir ein INNER JOIN auch nicht wirklich sinnvoll.

Glücklicherweise arbeit ich nicht mit Oracle-spezifischen Statements

[himitsu]

Zitat:

autsch vergessen

drum mach ich bei Umbenennungen auch immer das AS rein, auch wenn es viele DBs implizit machen.
feld_oder_tabelle AS anderer_name
statt
feld_oder_tabelle anderer_name
damit das nicht genauso aussieht, wie ein vergessenes Komma zwischen zwei Feldern/Joins

[MyRealName]

Ist auch nicht schön und manchmal falsch, wenn man mixed Joins macht, also sowas wie

Code:

...
FROM Tab1, Tab2
LEFT JOIN Tab3 on (...)
...

Firebird 3 zum Bsp. mag das garnicht mehr.

[Jumpy]

Zitat von MyRealName:

Ist auch nicht schön und manchmal falsch, wenn man mixed Joins macht, also sowas wie

Code:

...
FROM Tab1, Tab2
LEFT JOIN Tab3 on (...)
...

Firebird 3 zum Bsp. mag das garnicht mehr.

Das war das worauf ich eigentlich hinauswollte, das mixen der Join-Syntax. Egal ob die DB das nun kann oder nicht. Aber das ist halt, wenn es so funktioniert, letztlich eine Geschmacksache. Also schön das wir drüber geredet haben, kein Grund lang zu diskutieren oder streiten.

Nur zur Klarstellung:
FROM Tab1, Tab2 WHERE Tab1.A=Tab2.A
und
FROM Tab1 INNER JOIN Tab2 ON Tab1.A=Tab2.A
sind beides inner joins, nur halt alte und neue Syntax (wobei neu nun nicht wirklich neu ist).

[Ghostwalker]

Zitat von himitsu:

Zitat:

autsch vergessen

drum mach ich bei Umbenennungen auch immer das AS rein, auch wenn es viele DBs implizit machen.
feld_oder_tabelle AS anderer_name
statt
feld_oder_tabelle anderer_name
damit das nicht genauso aussieht, wie ein vergessenes Komma zwischen zwei Feldern/Joins

Und das hat mit den Kommas am Ende der Joins...was zu tun ? Die waren nämlich die Ursache des Problems