SQL-Optimizer ist einfach blöd

[BenderD]

@optimize Klausel:
soweit ich das sehe ist das kein SQL Standard! genauso wie irgendwelches rumbasteln an SQL Statements um die Macken von Query engines auszubügeln, für SQL gilt immer: entscheidend ist, was hinten rauskommt.

@sauber:
ich mache seit Jahren nichts anderes und genau daher kommen meine negativen Wertungen zur SQE. Weiterentwicklung der DB2/400 muss am SQL Ende stattfinden und nicht an der Altlastenfront, wenn IBM die Büchse weiter halten will.

@Perspektiven CQE:
ich glaube nicht, dass IBM in dieser Frage Herrn Fürchau, Frau Hauser oder mich konsultieren wird!!!

D*B

Noch besser ist es, Du gibts im embedded SQL das Optimierungsziel immer am Ende eines SELECT-Statements an und übernimmst dann dieses Ziel, wenn Du die Abfrage interaktiv ausführst.

Nur wer eine einigermaßen saubere SQL-Datenbank mit Referentiellen Integritäten und sauberen SQL-Indices hat, hat das Vergnügen sich mit der SQE herumzuschlagen. (Deshalb auch mein Kommentar von gestern, dass in den meisten Fällen, in denen auf die SQE geschimpf wurde und wird, die CQE die Abfragen ausführt.)

Die CQE wird genauso verschwinden wie die /36-Umgebung und der RPGIII-Compiler ... also uns noch einige Zeit erhalten bleiben.

Birgitta

[Fuerchau]

Ich habe mich bei unserer BI-Anwendung damals für die von Dieter angegebenen Firebird-Datenbank entschieden.
Gerade was den Optimizer angeht, könnte IBM doch von dieser OpenSource-DB viel lernen.
Dieses gehuddel mit "Optimize for" kann ich deshalb nicht nachvollziehen.

Wieso verändert STRSQL meinen eingegebenen Select mit einer eigenständigen Optimize-Klausel ?
Das gehört verboten!
Wie soll man denn da vernünftige Entscheidungen bezgl. des SQL's treffen ?
Ich baue viele SQL's erst mal per STRSQL bevor ich mich der Mühsal des Programmtestens unterziehe.
Den OpsNav verwende ich da nicht, da mir das einfach zu langsam geht und tatsächlich nervt.

Der Vorteil von embedded SQL's insbesonders dem Einbinden von Servicemodulen (auch in OPM-Konzepten durchaus vorhanden), die sowohl in Batch als auch Dialog aufgerufen werden ist somit dahin.

Ich muss also in den Programmen abfragen, ob es ein Dialog- oder Batchprogramm ist um den entsprechenden statischen SQL aufzurufen ?
Der Jobstatus alleine reicht da nun mal nicht mehr aus, da es auch Batch-Services gibt, die eigentlich auf Dialog ausgerichtet sind (Web-Services).

Und was passiert, wenn man mal per RDB auf eine AS/400 durchgreift, die den Optimize for noch nicht kennt ?

Also alles nicht so schön, wie IBM immer beschreibt.
Da kann ich nun langsam die Anwender verstehen, dass sie zu SQL-Server oder Oracle wechseln, wenn es um SQL-Anwendungen geht (nicht nur wegen der bunten Oberflächen).

PS:
Und was die Compiler angeht, so ist ja das Lizenzmodell ab V6 erschreckend, dass man nun 2 Compilergruppen hat:
1. preiswerte ILE-Compiler
2. teure OPM-Compiler mit Tendenz zum Verschwinden
Bei tausenden OPM-Anwendungen, die sicherlich auch noch nach V6 gewartet und auch als OPM erweitert werden müssen, ist das kein gutes Zeichen.