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 :wall:

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:

Zitat von jobo (Beitrag 1467760)

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:

Zitat von jobo (Beitrag 1467760)

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:

Zitat von Jumpy (Beitrag 1467754)

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 :lol:

[himitsu]

Zitat:

autsch vergessen

drum mach ich bei Umbenennungen auch immer das AS rein, auch wenn es viele DBs implizit machen.

SQL-Code:

feld_oder_tabelle AS anderer_name

statt

SQL-Code:

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:

Zitat von MyRealName (Beitrag 1467779)

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. :-D

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:

Zitat von himitsu (Beitrag 1467777)

Zitat:

autsch vergessen

drum mach ich bei Umbenennungen auch immer das AS rein, auch wenn es viele DBs implizit machen.

SQL-Code:

feld_oder_tabelle AS anderer_name

statt

SQL-Code:

feld_oder_tabelle anderer_name

damit das nicht genauso aussieht, wie ein vergessenes Komma zwischen zwei Feldern/Joins

:gruebel:

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

[Delphi.Narium]

Ein Komma darf es nur geben, wenn es auch ein AS gibt, sonst ist das Komma falsch.

Erleichtert einfach die optische Fehlererkennung und macht (für meine Begriffe) die SQLs insgesamt leichter lesbar.

AS gesehen: Ist dahinter ein Spaltenname.
Kein AS gesehen: Ist dahinter ein Tabellenalias.

Hinter AS in der Zeile folgt immer ein Komma, außer beim letzten AS.
Ansonsten ist ein Komma eher :evil:
Achso: Habe mir angewöhnt in SQLs den Spalten immer eine eigene Zeile zu gönnen und nicht "endloslange" Spaltenlisten in einer Zeile zu "verbraten".
Macht's für mich halt lesbarer und das einfügen oder entfernen von Spalten an der richtigen Stelle im Statement wird auch irgendwie einfacher.

Aber das ist halt auch nur 'ne sehr subjektive Ansicht, die niemand teilen muss (aber durchaus darf ;-)).

[Ghostwalker]

Zitat:

Zitat von Delphi.Narium (Beitrag 1467813)

Ein Komma darf es nur geben, wenn es auch ein AS gibt, sonst ist das Komma falsch.

Erleichtert einfach die optische Fehlererkennung und macht (für meine Begriffe) die SQLs insgesamt leichter lesbar.

AS gesehen: Ist dahinter ein Spaltenname.
Kein AS gesehen: Ist dahinter ein Tabellenalias.

Hinter AS in der Zeile folgt immer ein Komma, außer beim letzten AS.
Ansonsten ist ein Komma eher :evil:
Achso: Habe mir angewöhnt in SQLs den Spalten immer eine eigene Zeile zu gönnen und nicht "endloslange" Spaltenlisten in einer Zeile zu "verbraten".
Macht's für mich halt lesbarer und das einfügen oder entfernen von Spalten an der richtigen Stelle im Statement wird auch irgendwie einfacher.

Aber das ist halt auch nur 'ne sehr subjektive Ansicht, die niemand teilen muss (aber durchaus darf ;-)).

Nochmal..das hat nix mit AS zu tun.

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 rot markierten waren das Problem. Und an der Stelle kommt kein AS.

[Delphi.Narium]

Zitat:

Zitat von Ghostwalker

Die rot markierten waren das Problem. Und an der Stelle kommt kein AS.

Eben und darum hat es ja mit dem AS zu tuen.

Da steht kein AS und deshalb ist das Komma falsch!

Also: Ein Komma darf es nur geben, wenn es auch ein AS gibt, sonst ist das Komma falsch.

Oder: Kein AS = Kein Komma

Oder

Delphi-Quellcode:

for Zeile := 0 to SQL.Count - 1 do begin
  if (pos(' AS ',SQL[Zeile]) = 0) and (pos(',',SQL[Zeile]) <> 0) then begin
    Raise Format('In Zeile %d des SQL-Statements ist ein Komma zuviel.',[Zeile]);
  end;
end;

oder so ähnlich ungefähr ;-)

[DasWolf]

Zitat:

Zitat von Delphi.Narium (Beitrag 1467813)

AS gesehen: Ist dahinter ein Spaltenname.
Kein AS gesehen: Ist dahinter ein Tabellenalias.

Das ist vielleicht für Dich selbst so festgelegt.

Laut Deiner Definition soll also folgendes möglich sein?

LEFT JOIN country_names AS cn ON cn.cn_cid = c.country_id AND cn.cn_lang = l.lang_id,

[himitsu]

Zitat:

Zitat von Ghostwalker (Beitrag 1467799)

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

Mit dem AS dazwischen fällt es eher auf, ob da ein Komma fehlt, bzw. ob da wirklich nichts reingehört.

[Delphi.Narium]

Zitat:

Zitat von DasWolf (Beitrag 1468017)

Zitat:

Zitat von Delphi.Narium (Beitrag 1467813)

AS gesehen: Ist dahinter ein Spaltenname.
Kein AS gesehen: Ist dahinter ein Tabellenalias.

Das ist vielleicht für Dich selbst so festgelegt.

Laut Deiner Definition soll also folgendes möglich sein?

LEFT JOIN country_names AS cn ON cn.cn_cid = c.country_id AND cn.cn_lang = l.lang_id,

Ist denn country_names ein Spaltenname, dessen Alias man mit oder ohne As angeben kann?

Also nochmal ein Versuch:

Ein Komma darf es nur geben, wenn es auch ein AS zur Benennung eines Alias zu einem Spaltennamen gibt, ansonst könnte das Komma falsch sein, vorausgesetzt, dass das AS ist richtig.

Wenn ich z. B. eine Tabelle habe, die AS heißt oder einen Spaltenalias, den ich AS nenne oder eine Spalte, die AS heißt, könnte durchaus die Möglichkeit bestehen, dass meine Regel, die ich nur zur Vereinfachung der Fehlersuche nutze, nicht zwingend 100%ig zutreffend ist.

Frei nach dem Motto: Ausnahmen bestätigen die Regel ;-)