View Full Version : SQL-Update mit inner join
Hallo Zusammen,
ich versuche derzeit einen update, welcher aber nur über Kriterien einer zweiten funktioniert. Ich versuche es mal anhand eines Beispiels zu erklären.
(Sollen plakativ sein und keinen Standards entsprechend ;-) )
Tabelle Abteilungszuordnung:
Name Abteilung
Müller EDV
Frei EDV
Tablle Adressen
Name Ort
Müller Musterstadt
Frei Testort
Ich will die Abteilung, jedes Mitarbeiters, welcher in Musterstadt wohnt, auf IT ändern.
Habe mehere Ansätze versucht, aber keiner hat zum Erfolg geführt.
Schon mal danke :)
Update Abteilungszuordnung a
set Abteilung = 'IT'
where a.Name in
(Select Name from Adressen b
where b.Ort='Musterstadt')
ohne das jetzt selbst getestet zu haben.
Gruß
Ronald
Besser ist:
update MyFile A
set Field = xyz
where exists (select * from MyFile B where A.Key = B.Key)
Gibt es eigentlich eine Möglichkeit, auf der AS400 den Ausführungsplan anzuzeigen?
... STRDBG, zum Beispiel.
Ich meinte etwas vergleichbares zu dem folgenden Windows/Linux-Programm
The db2expln tooldescribes the access plan selected for SQL and XQuery statements.Use the tool to obtain a quick explanation of the chosen access planwhen explain data was not captured.
https://www.ibm.com/support/knowledgecenter/SSEPGG_9.8.0/com.ibm.db2.luw.admin.cmd.doc/doc/r0005736.html
Im iSeries-Navigator, Menü SQL, und ggf. auch im neuen iSeries-Director.
Bestimmt weiß Birgitta da mehr.
... da gibt es ein Redbook Query optimization - Google weiß wo. Wobei anzumerken ist, dass die diagnostics im Joblog (bei STRDBG) und der Database Monitor die realen Verhältnisse zur Laufzeit abbilden und Visual explain eher zum Spielzeug gehört, wie db2expln übrigens auch. Das sind reine Schätzungen, die mit den Verhältnissen zur Laufzeit nix zu tun haben müssen. Zur Laufzeit könnte selbst der Ausführungsplan abweichend sein!
D*B
@Fuerchau: Cool, danke. Da habe ich den Navigator ja mal wieder total unterschätzt.
@BenderD: Das läuft nach dem Motto "trau keiner Statistik, die Du nicht selbst gefälscht hast". Das ist mir völlig klar. Trotzdem hilft mir das bei der Entwicklung weiter, wenn ich die Schätzung habe. Vielen Dank für die Info. Ich werde mal Google nach dem Redbook fragen.
Also für die Entwicklung verlasse ich mich immer auf die Ausgaben des Debug-Modus.
Die 1. Optimierung kann sehr unterschiedliche ausfallen, wenn das betroffene Volumen trotz identischem SQL jedoch unterschiedlich ist.
Die 2. Abfrage wurd u.U. auch noch mal optimiert, anschließend bleibt aber der ODP auf (immer erst ab der 1. Wiederholung!) und SQL verlässt sich dann auf den Zugriffsplan.