SQL Date Between möchte einfach nicht gelingen

[BenderD]

... das Problem bei komplexen SQL Abfragen ist die Reihenfolge der Ausführung der Bestandteile des Statements in Abhängigkeit von der gewählten Zugriffsstrategie. Da kann ich mir sauber ausgedacht haben, bestimmte Sätze in der where Klausel wegzuschmeißen und der Query Optimizer entscheidet sich; da mache ich eine Zwischentabelle, über die ich dann einen full tablescan mache...
Das kann selbst dann passieren, wenn ich Bedingungen, die nur für eine Tabelle gelten in die join Klausel packe (was man immer tun sollte); auch da gibt es noch den Aetsch Zweig des Query Optimizers (da mache ich einen cross join und dann einen full table scan...)

Verschärft hat sich das Problem durch komplexere Statements und Verbesserungen der Query Engine in Folge schnellerer Hardware: je schneller die Hardware, umso eher sind Full table scan und temporäre Index by the fly von Vorteil (oder werden dafür gehalten).

Birgittas Vorschlag das in eine View zu verschieben, klingt gut, funktioniert aber genauso wenig wie ein CTE (common table Expression), da der Query Optimizer die Freiheit hat, die Bedingungen der View in das SQL Statement aufzunehmen - und dann bin ich sogar weiter weg von der Lösung (da man nicht direkt sieht, was in der View an Bedingungen und Konvertierungen steht). Es gibt in SQL keine stringente Möglichkeit der Query Engine eine Reihenfolge der Auswertung vorzuschreiben! (momentan geht noch die Verlagerung in eine stored Procedure oder eine UDTF, sobald der Optimizer da rein guckt, um das noch zu optimieren...) Selbst wenn der Query Optimizer nicht im Recht ist, weil die Umwandlung des SQL Statements nur fast äquivalent war, hilft mir das wenig und mit der Komplexität nimmt die Wahrscheinlichkeit von Bugs in der Query engine zu.

Huddelfreie Daten helfen Probleme zu vermeiden, aber auch das nicht immer (wenn z.B. ein Fulltable scan über einen cross join einfach zu langsam wird...) und viel zu oft hat man auch strukturellen Huddel in den Daten.

Macht man BI in einem "echten" Daten-Karstadt (AKA DWH), sollte das der ETL Prozess leisten (das T steht für Transform und da wird der Müll aus den Daten raussortiert, bzw. zu verwertbaren Daten recycelt). Versucht man BI auf Rohdaten, muss man Teilbereiche denormalisieren, im einfachsten Fall, indem man Extrakte zieht, die man dann weiterverarbeitet (aus einem SQL Statement werden dann mehrere, die temp tables erstellen, die man weiterverarbeitet), damit löst man viele Problem, aber nicht alle...

Die zweite Technik sind dann statische Hilfstabellen (habe ich am Beispiel einer Zeit Hierarchie in einem vorherigen Beitrag erläutert); das geht aber nur bei Wertebereichen mit überschaubarer Kardinalität so einfach.

Die nächste Stufe sind dann gleichartige Hilfstabellen, deren Größe man dadurch im Zaume hält, dass man nur das reinnimmt, was tatsächlich vorkommt (damit kann man selbst abenteuerliche Problem, wie numerische Daten in Alphafeldern, in denen noch eins, zwei drei oder Zahlen plus Währungsbeträge oder null komma nix drinsteht heilen). Da erstellt man vorab eine bereinigte Umsetztabelle, die man dann joined; will man die immer adhoc haben, kann man die auch per Trigger auf die Originaltabelle mit pflegen und aktuell halten.

D*B

[Fuerchau]

Was soll man machen, wenn man auf Daten aus 20-jährigen ERP-Systemen auswerten will?
Ich habe ja gerade bei diesen ETL-Prozeduren aus verschiedensten Datenbanken genau diese verschiedenen Probleme.
Und da man sich halt auf den Optimizer nicht verlassen kann und der sowieso macht was er will muss man sich halt mit den Problemen herumschlagen.
Man kann auch nicht einfach so die Datenbasis ändern, denn immerhin läuft das ERP noch immer so und arbeitet eben nicht mit SQL. Und wenn es dann sog. allgemeine Tabellen gibt, die diverseste Daten aufnehmen so ist man halt bei ETL-Prozessen auf entsprechende SQL-Logik angewiesen.
Sicherlich muss man bei SQL lernfähig sein, denn was eben vor 10-15 Jahren galt führt eben heute zu Problemen.
Auf V5R1 habe ich eben schon mit SQL "rumgemacht" und es funktionierte eben ohne jedwede Veränderung bis V5R4. Erst der Wechsel dann auf V6R1 hat dank des Optimizers zum Absturz der SQL's geführt da der nun von nun an mal einen anderen Weg eingeschlagen hat.
Hätte ich mein Wissen von heute bereits vor 10 Jahren einsetzten können, wären diese Probleme eben nicht aufgetreten.
Da man kann gerne mit modernem Wissen daherkommen, wenn es dann vor 10 Jahren auch schon so gewesen wäre.
Und wer weiß, ggf. werden reine SQL-Prozeduren/Funktionen auch noch mal (wie Dieter schon sagte) optimiert.

[Fuerchau]

Nachtrag:
Und gerade was ETL angeht so ist es durchaus üblich, auf dem Quellsystem nichts ändern zu dürfen.
So schön das erstellen einer View oder UDF/UDT, einer Hilfstabelle auch wäre, es ist nicht erlaubt und wird auch nicht bezahlt. Ich kann dem Kunden nicht sagen, na dann, dann kann ich die Daten eben nicht auswerten.
Irgendeine Lösung gibt es immer.

@Birgitta
Ich habe mich ja nicht beschwert sondern nur darauf hingewiesen, dass man bei seinen Casts und Berechnungen eben genau das machen muss was du mir ja geradezu bestätigst.
Warum wiederholst du mich also nur und stellst es andersherum dar?
Und ich wollte eben nur darauf hinweisen, dass der Optimizer eben je nach Release und Lust und Laune anders entscheidet.
Bei einem ERP-System haben wir diverse UDF's generiert, die Standardfunktionalitäten der ERP-Software zur Verfügung stellten. Bis V6R1 war auch alles gut.
Seit V7R1 interressiert sich aber der Optimizer nicht mehr für Zwischensortierungen (also order By in CTE/Derived Tables). Diese kann man nun auch durchaus getrost vergessen.
Einzige Ausnahme sind scalare Subselects mit "Order by" und "Fetch first 1 rows only", diese funktionieren nach wir vor.
Ich war daher gezwungen, die UDF's mit eigenen Cachefunktionen zu ergänzen um immer noch performant arbeiten zu können.
Wie gesagt, je nach Release stoße ich halt immer mal wieder auf Neuerungen des Optimizers, die zu Verschlechterungungen bisheriger SQL's führen.
So extrem ist es leider erst seit V6R1, bis V5R4 waren die SQL's auch aus V4R3 noch kompatibel.

[BenderD]

Was soll man machen, wenn man auf Daten aus 20-jährigen ERP-Systemen auswerten will?
Ich habe ja gerade bei diesen ETL-Prozeduren aus verschiedensten Datenbanken genau diese verschiedenen Probleme.

Und gerade was ETL angeht so ist es durchaus üblich, auf dem Quellsystem nichts ändern zu dürfen.
So schön das erstellen einer View oder UDF/UDT, einer Hilfstabelle auch wäre, es ist nicht erlaubt und wird auch nicht bezahlt.

... für einen ETL Prozess reichen nach meiner Erfahrung singuläre SQL Statements nicht aus. Auch und gerade, weil die bei einem Problem an nicht vorhersehbarer Stelle einfach abbrechen. Wenn der ETL Prozess remote laufen soll und nur den Datenbank connect nutzen darf, dann muss die Komplexität auf die Maschine, auf der der Prozess läuft, verlagert werden - oder man hat die Probleme, die Du beklagst...

D*B