SQL Create view V5R4

[KingofKning]

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]

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]

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]

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]

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]

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