AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren

Komplexe Abfrage

Ein Thema von Ghostwalker · begonnen am 18. Jun 2020 · letzter Beitrag vom 23. Jun 2020
Antwort Antwort
Seite 1 von 2  1 2   
Ghostwalker

Registriert seit: 16. Jun 2003
Ort: Schönwald
1.299 Beiträge
 
Delphi 10.3 Rio
 
#1

Komplexe Abfrage

  Alt 18. Jun 2020, 19:37
Datenbank: SQLite • Version: 3.24 • Zugriff über: FireDAC
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 ?
Uwe
e=mc² or energy = milk * coffee²
  Mit Zitat antworten Zitat
Ghostwalker

Registriert seit: 16. Jun 2003
Ort: Schönwald
1.299 Beiträge
 
Delphi 10.3 Rio
 
#2

AW: Komplexe Abfrage

  Alt 18. Jun 2020, 19:53
Autsch

die Kommas bei den Joins weglassen, dann gehts !.
Uwe
e=mc² or energy = milk * coffee²
  Mit Zitat antworten Zitat
Jumpy

Registriert seit: 9. Dez 2010
Ort: Mönchengladbach
1.733 Beiträge
 
Delphi 6 Enterprise
 
#3

AW: Komplexe Abfrage

  Alt 19. Jun 2020, 11:14
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;
Ralph
  Mit Zitat antworten Zitat
jobo

Registriert seit: 29. Nov 2010
3.072 Beiträge
 
Delphi 2010 Enterprise
 
#4

AW: Komplexe Abfrage

  Alt 19. Jun 2020, 11:31
"..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.
Gruß, Jo
  Mit Zitat antworten Zitat
Jumpy

Registriert seit: 9. Dez 2010
Ort: Mönchengladbach
1.733 Beiträge
 
Delphi 6 Enterprise
 
#5

AW: Komplexe Abfrage

  Alt 19. Jun 2020, 12:49
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.

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.
Ralph
  Mit Zitat antworten Zitat
Ghostwalker

Registriert seit: 16. Jun 2003
Ort: Schönwald
1.299 Beiträge
 
Delphi 10.3 Rio
 
#6

AW: Komplexe Abfrage

  Alt 19. Jun 2020, 12:57
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
Uwe
e=mc² or energy = milk * coffee²

Geändert von Ghostwalker (19. Jun 2020 um 13:01 Uhr) Grund: Ergänzung
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
43.017 Beiträge
 
Delphi 12 Athens
 
#7

AW: Komplexe Abfrage

  Alt 19. Jun 2020, 13:22
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
Garbage Collector ... Delphianer erzeugen keinen Müll, also brauchen sie auch keinen Müllsucher.
my Delphi wish list : BugReports/FeatureRequests
  Mit Zitat antworten Zitat
Benutzerbild von MyRealName
MyRealName

Registriert seit: 19. Okt 2003
Ort: Heilbronn
673 Beiträge
 
Delphi 10.4 Sydney
 
#8

AW: Komplexe Abfrage

  Alt 19. Jun 2020, 13:27
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.
  Mit Zitat antworten Zitat
Jumpy

Registriert seit: 9. Dez 2010
Ort: Mönchengladbach
1.733 Beiträge
 
Delphi 6 Enterprise
 
#9

AW: Komplexe Abfrage

  Alt 19. Jun 2020, 14:20
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).
Ralph
  Mit Zitat antworten Zitat
Ghostwalker

Registriert seit: 16. Jun 2003
Ort: Schönwald
1.299 Beiträge
 
Delphi 10.3 Rio
 
#10

AW: Komplexe Abfrage

  Alt 19. Jun 2020, 16:18
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
Uwe
e=mc² or energy = milk * coffee²
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 1 von 2  1 2   

Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 12:24 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz