SQL Performance

[Fuerchau]

Das ist keine Anwendung für eine VIEW wenn du auf die View auch noch einen Select losläßt.

Concats im Join führen fast IMMER zu einem Tablescan, was die Laufzeit erklärt.

Hier streikt auch der Optimizer, da erst eine temporäre Tabelle (bzw. Index) für die View gebildet werden muss und erst DANACH die Daten selektiert werden.

case when t3.TEXT1G is null then ' ' else t3.text1g end

Besser "coalesce(TTEXT1G, ' ')"

Ein Typecast ist da nicht erforderlich.

Und nun überlege dir, wie du an Stelle der View den Select im Programm direkt aufbaust (s.o.) udn gezielt die Where-bedingungen berücksichtigst.

[Dirschl]

Das ist keine Anwendung für eine VIEW wenn du auf die View auch noch einen Select losläßt.

Jetzt bin ich verwirrt!

Für mich war bis jetzt DAS der klassische Fall für eine View:
Ich habe
- mehrere Tables
- die ich zusammenhänge
- und über SQL-Statements kreuz und quer selektieren kann.

Oder habe ich da irgendwo etwas missverstanden?

[Fuerchau]

Wenn eine View bereits WHERE enthält und Joins Typecasting (auch concat) enthalten ist das die denkbar schlechteste Lösung.
Bei kleinen Datenbeständen mag das noch angehen und performant sein.

Bei diesen Datenbeständen jedoch ist das die Katastrophe (wie du ja selber merkst).

Views sind dann sinnvoll, wenn klare 1:N (n=1-32)-Beziehungen über fixe Schlüssel vorhanden sind.

Alles andere ist dann eher Anwendungslogik.

Zumal über Views kein Index angelegt werden kann !

Allerdings:
Whereklauseln sind nicht unbedingt von Nachteil.
Und:

Zerlege die

t1.LGNT1G||t1.SCPB1G||t1.CMPN1G = '000000'

in

t1.LGNT1G = '00' and t1.SCPB1G='00' and t1.CMPN1G = '00'

Da wird dann direkt selektiert und nicht erst ein temporärer Index benötigt.

PS:
Wobei ich da keine Joinbeziehung erkennen kann.