SQL join mit nur letztem Satz

[B.Hauser]

Mir ist nachwie vor nicht klar warum ihr unbedingt LATERAL verwenden wollt!
Die beste Lösung (i.Ü. auch die performanteste) ist die Lösung von Dieter, d.h. die Verwendung von Common Table Expressions.

Die Lösung mit LATERAL ist ungeführt 3x langsamger wie die Lösung mit CTE. Sagt zumindest Visual Explain, wenn man beide Syntaxen durchlaufen lässt. Ich habe leider in meinen Spiel-Dateien nicht genug Daten, so dass man den Unterschied tatsächlich merken könnte.

... das behauptet auch ChatGPT:
Du liegst mit deiner Strategie (CTEs > Subselects/OLAP > LATERAL/Skalare) vollkommen richtig – besonders in einem System, das du verstehen, testen und langfristig warten möchtest.

[KingofKning]

Mir persönlich ging es eigentlich nur darum zu zeigen wie gut die Antworten auf die gestellten Fragen waren.
Ich bin von beiden Antworten positiv überrascht und hätte nicht vermutet das eine Software die in meinen Augen gute Lösung in sekundenschnelle liefert.

Wenn ich noch Programmierer wäre bekäme ich langsam Angst um meinen Job.

GG 2139

[Peet]

Mir persönlich ging es eigentlich nur darum zu zeigen wie gut die Antworten auf die gestellten Fragen waren.
Ich bin von beiden Antworten positiv überrascht und hätte nicht vermutet das eine Software die in meinen Augen gute Lösung in sekundenschnelle liefert.

Wenn ich noch Programmierer wäre bekäme ich langsam Angst um meinen Job.

GG 2139

Vielen Dank.
Es freut micht dass du mit ChatGtp in so kurzer Zeit ein Ergebnis erzielt hast.
vg.
Peet

[Peet]

Mir ist nachwie vor nicht klar warum ihr unbedingt LATERAL verwenden wollt!
Die beste Lösung (i.Ü. auch die performanteste) ist die Lösung von Dieter, d.h. die Verwendung von Common Table Expressions.

Die Lösung mit LATERAL ist ungeführt 3x langsamger wie die Lösung mit CTE. Sagt zumindest Visual Explain, wenn man beide Syntaxen durchlaufen lässt. Ich habe leider in meinen Spiel-Dateien nicht genug Daten, so dass man den Unterschied tatsächlich merken könnte.

... das behauptet auch ChatGPT:
Du liegst mit deiner Strategie (CTEs > Subselects/OLAP > LATERAL/Skalare) vollkommen richtig – besonders in einem System, das du verstehen, testen und langfristig warten möchtest.

Hallo Birgita,
vielen Dank für die Infos.
Vg.
Peet

[Fuerchau]

@Birgittta
Meine Erfahrung spricht da vollkommen dagegen.
Lateral Table ist die bisher schnellste Möglichkeit, wie ich festgestellt habe, z.B. per where ... Order By ... Limit n, Sätze zu joinen oder eben auch einen "select Aggregates from .. where .." ohne aufwändigen Group by zu verknüpfen.
Der Lateral ist letztlich genauso schnell wie die "Aggr() Over()"-Funktionen, die man früher auch mit CTE's o.ä. lösen musste. Und dagegen hast du ja auch nichts.

Per CTE oder auch derived Table einen Grouped Join durchzuführen ist merklich langsamer.
Dasselbe gilt auch für skalare Subselects, die damit vollkommen obsolet werden, zumal man mit den Ergebnissen des Laterals auch gleich weiterrechnen kann.
Vielleicht probiert du ihn einfach auch mal aus. Vor allem auf Tabellen mit ein paar 100.000 oder mehr Zeilen. Auf Testumgebungen mit ein paar 1000 Zeilen macht das natürlich kaum einen Unterschied.

Also rede den Leuten nicht ein, dass Lateral Unsinn sei. Es ist einer der effektivsten Joins überhaupt und so komplizierte CTE's wie oben angegeben sind nicht mehr erforderlich. Ich verwende den für fast alle Belange, die früher ungleich komplizierter waren.

[BenderD]

... imho sind ANSI konforme Konstrukte vorzuziehen und die einfachste, am besten lesbare Variante ist am besten. Wenn dann eine Variante langsamer ist, taugt der Optimizer nichts. Am Rande sei noch vermerkt, dass komplizierte SQL Statements auch ein Zeichen für lausiges Datenbankdesign sein könnten.

Der Griff nach KI ist meist ein Zeichen von Mangel an NI oder Faulheit - kann aber nach umgekehrtem Eiffelturm-Prinzip durchaus Karriere-fördernd sein.

D*B

[Fuerchau]

Ich habe mir nun mal die Mühe gemacht, den Explain mi den SQL's zu prüfen:

left join Lateral mit where order by limit
führt zu
Index Probe => Table Probe => Fetch n Rows => nested Loop Join

left join CTE mit On-Klausel führt zu
Index Probe => Table Probe => Aggregation => nested Loop

Der Unterschied ist, dass nach dem Lateral nur noch ein Fetch einer Zeile passiert, während bei dem Grouped-Join noch ein Aggregat gebildet werden muss, was durchaus mehr als 1 Zeile umfassen kann.

Gegen den CTE spricht ebenso, dass ich einen 2. Left join mit dem CTE benötige, wenn ich weitere Werte aus dem Satz haben muss.
Das funktioniert halt nicht mit dem CTE, da ich hier einen Group By benötige um Aggregate verwenden zu können.
Dies führt dann zu einem 2. Index Probe => Table Probe => nested Loop

Wie du an meinem Lateral siehst, benötige ich nur ein b.* um aus dem Lateral alles zu erhalten, was ich benötige.

Ein weiteres Argument gegen CTE's ist leider auch, dass ich diese nicht in einem Insert oder Merge verwenden kann, sondern hier auf derived Table gehen muss.

Es gibt aber noch eine weitere Anwendung für lateral.
Wer kennt nicht die Tabellen mit pseudo Array-Feldern, die durchnummeriert sind.
Bisher musste man diese mit einem etwas kompexeren union all trennen um sie per SQL vernünftig zu verarbeiten:

select artikel, menge01 as menge from myfile
union all
select artikel, menge02 as menge from myfile
:

Dies führt dann zu n * Indexscan => Table Probe => union all

Mit Lateral ist das nun erheblich einfacher:

select artikel, x.* from myfile
cross join lateral (
  values(menge01)
   union all 
  values(menge02)
) x (menge)

Dies führt zu n * values list => union all => nested loop

Außerdem gehört Lateral bei vielen anderen DBM's inzwischen zum Standard.

Wer mehr wissen will:
https://medium.com/@goldengrisha/a-d...n-7b09fcb3b745

[Fuerchau]

Weitere Beispiele zu Lateral (andere Dialekte), funktioniert auch in DB2 for i:
https://blog.jooq.org/lateral-is-you...iables-in-sql/

Beispiel aus dem Link:

SELECT actor_id, name, name_length, COUNT(*)
FROM
  actor JOIN film_actor AS fa USING (actor_id),
  LATERAL (SELECT first_name || ' ' || last_name AS name) AS t1,
  LATERAL (SELECT length(name) AS name_length) AS t2
GROUP BY actor_id, name, name_length
ORDER BY COUNT(*) DESC
LIMIT 5;

In DB2 for i

SELECT actor_id, name, name_length, COUNT(*)
FROM
  actor JOIN film_actor AS fa USING (actor_id),
  LATERAL (values( first_name || ' ' || last_name)) AS t1 (name),
  LATERAL (values( length(name))) AS t2 (name_length)
GROUP BY actor_id, name, name_length
ORDER BY COUNT(*) DESC
LIMIT 5;

Interessant wirds dann bei Embedded SQL und Parametern:

select a.*
        ,a.Preis * Faktor
  from Artikel a
  cross join lateral(
      values( :P1, :P2)
    ) p (Artikelnummer, Faktor)
where a.Artikelnummer = p.Artikelnummer

Vor allem, wenn man Parameter mehrfach in unterschiedlichen Teilen des SQL's benötigt, braucht man Parameter nur noch 1x per Lateral anhängen, da sie dann überall verwendet werden können. Somit ist die Wartung komplexer SQL's einfacher, wobei die Komplexität sogar noch sinkt.

Lateral wird im Gegensatz zum normalen Join für den Einzelzugriff optimiert und entspricht eher dem Programmiergedanken mit den Dateien.

Übrigens wurde Lateral mit SQL99 bereits eingeführt:
https://elephantdolphin.blogspot.com...ved-table.html

Und für die IBM kam es etwas später:
https://www.rpgpgm.com/2021/10/using...al-in-sql.html
Hier kann man auch schön sehen, dass ein Cross-Join durchaus Sinn macht.

Probierts einfach aus, es ist wirklich genial!

[camouflage]

Der Griff nach KI ist meist ein Zeichen von Mangel an NI oder Faulheit - kann aber nach umgekehrtem Eiffelturm-Prinzip durchaus Karriere-fördernd sein.

Dieter, Dieter,
Hallo, wir sind nun mal in dieser KI Zeit angekommen, warum denn nicht auch diese nutzen? Ja, ich brauche ChatGPT ziemlich häufig, weil mir dieser die Statements ziemlich zuverlässig zusammenstellt, bei entsprechender Problemstellung.

Und es ist nicht ein Mangel an NI oder Faulheit, sondern ein Zeichen von Effizienz. Den Weg zur Lösung kenne ich ja, warum soll ich dann Zeit mit Tippen oder Suchen nach der korrekten Syntax verplempern.

Abgesehen davon ist die KI auch nicht immer glückselig machend, ohne Knowhow zur Kontrolle ist man hoffnungslos verloren.

[Fuerchau]

Stimmt, solange ChatGPT den Lateral nicht kennt, fühle ich mich im Vorteil;-).

[camouflage]

Stimmt, solange ChatGPT den Lateral nicht kennt, fühle ich mich im Vorteil;-).

Da wäre ich mir nicht so sicher.... ;-)

[BenderD]

Dieter, Dieter,
Hallo, wir sind nun mal in dieser KI Zeit angekommen, warum denn nicht auch diese nutzen? Ja, ich brauche ChatGPT ziemlich häufig, weil mir dieser die Statements ziemlich zuverlässig zusammenstellt, bei entsprechender Problemstellung.

Und es ist nicht ein Mangel an NI oder Faulheit, sondern ein Zeichen von Effizienz. Den Weg zur Lösung kenne ich ja, warum soll ich dann Zeit mit Tippen oder Suchen nach der korrekten Syntax verplempern.

Abgesehen davon ist die KI auch nicht immer glückselig machend, ohne Knowhow zur Kontrolle ist man hoffnungslos verloren.

... man muss nicht jedem Marketing Blödsinn hinterherlaufen. Aber jeder, wie er kann.