Komplexe Abfrage

[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

[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
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 von 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
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 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 von Delphi.Narium:

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,

[Delphi.Narium]

Zitat von DasWolf:

Zitat von Delphi.Narium:

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