PDA

View Full Version : SQL Create view V5R4



KingofKning
05-09-15, 09:19
Hallo *all,

ich wollte jetzt nochmal den Vorschlag von Birgitta aufnehmen und meine Daten per SQL bereitstellen anstatt mit Cobol zu lesen.

Ich habe mal folgendes getestet:

create view rptrade/testart2 as
select t01.adkto, t01.adknam, t02.teknam, artpreis3(adkto,t02.tetenr)
as "Preis"
from adr01pf t01, tst01pf t02
where adfa = 1
and adsts = 0
and adabkz = 0
and adsa06 = 101
and test23 = 1
group by adkto, adknam, teknam, PREIS00001

Ohne die UDF artpreis3 kann ich die View mit group by erstellen. Wenn ich mir das dann in Query ansehe, ist die Bezeichnung der UDF PREIS00001.

Wenn ich aber das Group by mit Preis000001 angebe sagt er mir das dieses Feld nicht existiert.
welche Angabe will er da von mir oder geht das grundsätzlich nicht?
Über das für und wieder von Group by in der View läßt sich ja streiten wie ich weis.....
Aber das ist hier mehr so eine Verständisfrage

B.Hauser
05-09-15, 09:45
Innerhalb des gleichen Sub-Selects, müssen die Ausdrücke wiederholt werden.
Die vergebenen Namen (in deinem Fall "Preis" = SQL-Name und PREIS00001 = System-Name) können nur außerhalb des Sub-Selects verwendet werden (so ist nun mal die Regel).

Ein Sub-Select kann bestehen aus:
SELECT, FROM, WHERE, GROUP BY, HAVING

Der Order By gehört zum Full- und nicht zum Sub-Select, deshalb können die vergebenen Namen dort verwendet werden.

Wenn Du den Ausdruck artpreis3(adkto,t02.tetenr) im Group By wiederholst, sollte es funktionieren.

Wie werden eigentlich die beiden Dateien verknüpft. M.E. generierst Du mit der Abfrage ein kartesisches Produkt, jeder Satz aus jeder Tabelle mit jedem Satz aus jeder Tabelle.

Birgitta

KingofKning
05-09-15, 11:10
Hallo, die Frage hatte ich fast erwartet. Ja, ich lese den kompletten Kundenstamm und dazu den kompletten Artikelstamm , da Kunde und Artikel so keine Beziehung haben, ich aber für jede Kunden / Artikel Konstellation einen Satz brauche. Danke für den Hinweis, werde ich nach meinem Nickerchen mal ausprobieren. GG Hat mich doch noch gereitzt. Funktioniert, aber was ich hasse ist der Satz "Abfrage läuft. Kopie von Datei *N in *N wird erstellt."

KingofKning
05-09-15, 18:35
Also, die Kopie von *N in *N dauert über 40 Minuten bei einer CPU Belastung von 60% ohne group by und einer Abfrage mit select * from order by bringt auch nichts, da er erst alle Sätze liest. Der Index-Advisor gibt aber auch keinen Hinweis.
In Summe irgendwie nicht so wie ich es mir vorgestellt habe.

Und das der dämliche Firefox alle Leerzeichen und Satzumbrüche frißt ist auch doof.

GG

Fuerchau
07-09-15, 06:58
Ein Group By über eine UDF kann nicht zu einem Index führen und benötigt halt einen Tablescan.
Je nach Größe dauert das halt.
Dass der Optimizer nun entscheidet, erst mal eine Kopie mit dem berechneten Ergebnis zu erstellen ist doch nur verständlich.

Was die Namensgebung angeht, so heißt dein Feld durch die Einbettung in Anführungszeichen immer "Preis", denn das ist casesensitive.

B.Hauser
07-09-15, 07:55
Aiuch ein Group By in dem eine UDF integriert ist, kann zum Gruppieren durchaus einen (Binary Radix oder Encoded Vector Index) verwenden, in dem alle zu verdichtenden Spalten oder ein Teil der verdichteten Spalten verwendet wird.

Der Kasus-Knacksus in dem Fall von KingOfKing, ist der cross join, da muss zunächst ein temporäres Objekt generiert werden, in dem jedem Satz aus der ersten Tabelle jeder Satz aus der zweiten Tabelle zugewiesen wird. Das Ergebnis kann nur ungeschlüsselt sein. Darauf wird dann der Group By losgelassen.
Die Frage ist, wie sollte denn überhaupt ein Index erstellt und verwendet werden, wenn weder eine Join-Anweisung noch eine where-Bedingung vorhanden ist? Es müssen ja immer alle Sätze gelesen werden.

Birgitta

Fuerchau
07-09-15, 08:00
Das sollte ja der Optimizer erkennen wenn ich dann per "Where" die View näher eingrenze.
Allerdings stimt es schon, dass zu einem Join auch eine Beziehung nötig ist.

Auf Grund der "alten" Schreibweise

from FileA A, FileB B
where A.Key = B.Key ...

sollte eher grundsätzlich
from fileA A
inner/left/exception join FileB B on A.Key = B.Key
kodiert werden.
Dann fällt sowas eher auf da das bereits der Syntaxchecker merkt.

B.Hauser
07-09-15, 08:29
Warum werden hier eigentlich Antworten gegeben, die mit der Frage nichts zu tun haben?


Ja, ich lese den kompletten Kundenstamm und dazu den kompletten Artikelstamm , da Kunde und Artikel so keine Beziehung haben, ich aber für jede Kunden / Artikel Konstellation einen Satz brauche.


KingOfKing hat in o.g. Antwort klargestellt, dass er einen Cross Join benötigt. Das hat nichts mit alter oder neuer Schreibweise zu tun. Zugegebenermaßen finde ich die Synax:
FROM Table1 Cross Join Table2
Besser als die simple Auflistung der einzelnen Tabellen.

Birgitta