SQL - Mehrere Sätze in einen Satz mit mehreren Spalten

[Fuerchau]

Wie immer gibt's natürlich viele Lösungen:

select
key, Name1
,(select Name2 from myfile b where a.key=b.key) name2
,(select Name3 from myfile b where a.key=b.key) name3
,(select Name4 from myfile b where a.key=b.key) name4
: -- je Spalte ein neuer Subselect
from myfile a

[B.Hauser]

@Baldur

Das könnte nur klappen, wenn die Namen immer Name1, Name2, Name3 und Name4 wären, wovon ich allerdings nicht ausgehe.
Des weiteren würde ich von dieser Lösung abraten, da durch die vielen unnötigen Sub-Selects die Performance in die Knie geht.

Birgitta

[BenderD]

@Baldur

Das könnte nur klappen, wenn die Namen immer Name1, Name2, Name3 und Name4 wären, wovon ich allerdings nicht ausgehe.
Des weiteren würde ich von dieser Lösung abraten, da durch die vielen unnötigen Sub-Selects die Performance in die Knie geht.

Birgitta

... den ersten Punkt teile ich (funzt net); den zweiten Punkt (Performance) ordne ich mal in die Rubrik "Wie sich Klein-Erna die Query Engine vorstellt" ein; Subselects werden zumeist in Joins aufgelöst, was auch gut so ist!

D*B

[Fuerchau]

Jo, da habe ich nicht genau hingesehen.

[B.Hauser]

ordne ich mal in die Rubrik "Wie sich Klein-Erna die Query Engine vorstellt" ein; Subselects werden zumeist in Joins aufgelöst, was auch gut so ist!

Die Query-Engine ist zwar besser geworden und erkennt und konvertiert inzwischen meist solche Konsturkte, ... aber eben nur meist!
Trotzdem ... bei 30 unnötigen Joins sind mindestes 29 zuviel!

Birgitta

[BenderD]

Die Query-Engine ist zwar besser geworden und erkennt und konvertiert inzwischen meist solche Konsturkte, ... aber eben nur meist!
Trotzdem ... bei 30 unnötigen Joins sind mindestes 29 zuviel!

Birgitta

... bezüglich Performance hilft nur messen, alles andere ist reine Kaffeesatzleserei!

[holgerscherer]

... bezüglich Performance hilft nur messen, alles andere ist reine Kaffeesatzleserei!

und dann nicht vergessen, dass sich der Kram je nach CPU-Typ (Power5,6,7,8) und Ressourcen-Ausstattung noch anders verhalten kann als gedacht

[Pikachu]

Und nach dem Einspielen von PTFs ...
Und nach Erstellen weiterer Zugriffspfade ...

und dann nicht vergessen, dass sich der Kram je nach CPU-Typ (Power5,6,7,8) und Ressourcen-Ausstattung noch anders verhalten kann als gedacht

[andreaspr@aon.at]

... bezüglich Performance hilft nur messen, alles andere ist reine Kaffeesatzleserei!

Sicher kann die DB immer andere Entscheidungen treffen als man sich das vorstellt, da viele Faktoren einfließen die oft nicht berücksichtigt werden.

Dass aber 30 subselects langsamer sind als 1 kann man in der Regel schon nachvollziehen.
In diesem Fall wird es vielleicht vernachlässigbar sein.
Merken tut man dies erst wenn es sich um eine oder mehrere wirklich große Tabellen handelt. (Aber nicht nur dann!)
Da kann es schnell mal passieren, dass Queries Minuten bis Stunden dauern.
Klar, kann in vielen Fällen mit Indices kompensiert werden, aber auch nicht immer.
Und genau da fängt das Tuning an und da gehören auch die Anzahl der Tabellen-Zugriffe beachtet.

Genau so habe ich z.B. schon viele Abfragen die bis zu 20 min dauerten wieder in den Millisec. bereich gebracht.

[wti]

Danke Birgitta,

deine Lösung funktioniert wunderbar. Die Anzahl der Namen ist auf 30 beschränkt, was natürlich dazu führt dass 30 CASE-Abfragen benötigt werden.
Ist aber schneller als ein RPG-Programm zu schreiben.

Gewusst wie!

LG
Wolfgang