View Full Version : SQL Schlüssel herausfinden
Hallo Baldur, Rince
schade, die Referenz auf C in der From Klausel habe ich glatt übersehen, also doch Brille und so.
Dann bleibt nur noch die Datenbanktechnische Umkehrlösung als Ansatz (oder ein anderes DBMS, das diese Union/In Schwäche nicht hat); das meint:
Gegenwärtig sind KRT001 und KRTHST Tables und es wird eine View KRT001 union KRTHST (nennen wir die mal KRTALL) benötigt. Umkehrlösung wäre: Table KRTALL (evtl. mit einem zusätzlichen Partitionierungsfeld) und KRT001 und KRTHST als Views.
mfg
Dieter Bender
@Dieter
Eine VIEW bringt hierzu nichts, da eine VIEW keine ORDER BY-Klausel enthalten darf.
Eine View im Join entspricht dem Konstrukt:
select .... from file1 a
[inner] join (select ... from fielex) as viewname on ...
Es gibt daher keinen Performance-Gewinn, sondern nur den Gewinn der Wiederverwendbarkeit eines Subselect.
Allerdings könnte der obige Select über den Join auf den Union-Select vereinfacht werden.
Hallo nochmal,
ich würde die Datenbank ändern!!! KRT001 und KRTHST in eine Datei KRTALL zusammen werfen mit einem zusätzliche Feld Herkunft unterscheidbar machen, ob die jemand in KRT001 oder KRTHST sehen will. Und dann mit zwei Views die Anwendungen bedienen, die jetzt KRT001 oder KRTHST verarbeiten.
In diesem konkreten Falle, könnte man sogar Programme, die record level access verwenden bedienen, wie vorher.
Dieter Bender
@Dieter
JETZT habe ich das auch verstanden;)
Hy,
das SQL würde somit bestimmt schneller laufen , also heissen Dank an euch 2,
aber die Antwort kam dann eigentlich mehr von Frau Hauser
Die Frage ist nur:
Kann ich das Verknüpfungskriterium TRFBCH weglassen oder muss ich es mit in den Schlüssel nehmen ? (Und wenn ja an welcher Stelle, vorne scheint nicht zu funktionieren)
Ich will eigentlich nur wissen wie ich diesen *MAP auflösen kann (Ops Navigator oder sonstige Tools)
Trotzdem danke für eure Mühen
Rince
Hallo Rince,
der Schlüssel zum Verständnis liegt immer in der Original Frage:
Nun sagt er mir aber leider nicht einen Schlüssel zur Optimierung (wie er es sonst so gerne macht) sondern gibt mir nur ein
*MAP ASCEND
als Schlüsselwort für die temporäre Datei an.
sobald der Query Optimizer sich entscheidet eine temporäre Zwischendatei anzulegen, sind mit zusätzlichen Indexen an dieser Stelle alle Spatzen gefangen.
Du hast in Deinem Query auf oberster Ebene einen Union, den Du dann per ORDER BY nach Feldern aus den beiden Dateien sortieren willst, dass die was miteinander zu tun haben merkt der Query Optimizer nicht und damit kann er auch nichts anfangen.
Alle Tricks die temporäre Tabelle zu verhindern helfen nix, da die View wg. der Gruppierung read only ist, alle Tricks einen bestimmten Zugriffspfad durch eine erweiterte ORDER BY Klausel zu favorisieren, scheitern letztlich daran, dass Zugriffs relevante Felder nicht im ResultSet sind.
Ich würde von der Analyse her im ersten Schritt den Union rausnehmen und die beiden resultierenden Queries unter debug ansehen, was der Optimizer macht - respektive empfiehlt. (das muss natürlich im Produktions Umfeld erfolgen: Datenmenge Batch oder interaktiv). Wenn hier keine Indexe mehr fehlen, dann den Union untersuchen - meine Erfahrung sagt mir aber, dass DB2/400 keinen Union kann; bis V5R1 nicht und das Marketing Getöse von der neuen 5.2er Query Engine sollte man mit Vorsicht genießen, die ist vielleicht mit V6 halbwegs fertig.
mfg
Dieter Bender
Bei Trennung verarbeitet er nach Eingangsfolge *grummel*
Guter tip allerdings :)
Naja mit dem Union scheint er so seine Probleme zu haben.
Aber egal ;) ich habs jetzt mit guten alten Read gelöst und das ist superschnell.
Dank euch für euer nachdenken
Der Rince