SQL-Statement zu aufwendig

[himitsu]

Wobei dein Code doch auch nur geht, wenn es für jeden Artikel (watenr+tebez1) maximal je einen Eintrag pro Zeitraum gibt. (und das sollten die ursprünglichen Joins auch hinbekommen, wenn vielleicht auch etwas langsamer).

Wobei bei den Joins alle Zeiträume in je einem Artikeldatensatz zusammen sein müssen, da sie sonst doppelt/mehrfach eingerecht werden.

[hstreicher]

Die Ergebniss ist wahrscheinlich falsch weil da nur auf Monat verglichen wird , d.h. es wir Mai 2014+Mai2013 +Mai2012 usw aufaddiert
da muss noch ein Vergleich auf Jahr hinein

Zur Geschwindigkeit, das extract kann keinen Index verwenden es führt immer zu einem Full Table Scan
schneller wird wenn man die Bedingungen mit

2014-05-01<=Liefertermin<=2014-05-31

eingrenzt dann kann ein Index auf Liefertermin verwendet werden und das Ergebniss stimmt auch

mfg Hannes

[Dejan Vu]

Zitat von hstreicher:

Die Ergebnisse sind wahrscheinlich falsch

Korrekt. Mein erster Ansatz war mit 'between' und dem vorherigen Ausrechnen der Monatsgrenzen, also so:

SQL-Code:

  ...
  SUM(IIF (ltlite between @firstOfMonth and @lastOfMonth, ltRest,0)) as 'Bedarf Monat'
  ...

Aber ich dachte, wenn er seine Monate haben will, soll er doch. Die Eingrenzung des Lieferdatums funktioniert wegen der Spalte 'Rückstände' nicht, denn man weiß nicht, wann der älteste Rückstand ist.

Bei einer Aggregierung über die Tabelle ist ein Scan zwingend. Bei sehr großen Tabellen könnte ein Index auf den Aggregatspalten etwas bringen, aber das dürfte auf das RDBMS ankommen.

[Sir Rufo]

In solchen Fällen kann es auch helfen, wenn man mit temporären Tabellen arbeitet.

Die zu untersuchende Datenmenge wird mit einem einfachen SELECT in eine auf die Suche passendes Format gebracht (z.B. der Monat) und eingeschränkt. Dann werden dort passende Indizes für die Suche (Spalte Monat) erstellt und mit dieser reduzierten Datenmenge wird dann die konkrete Abfrage durchgeführt.

BTW:

Trotz allem können solche Abfragen je nach Datenvolumen eine gewisse Zeit in Anspruch nehmen. Dann lässt man diese nicht synchron am Client laufen, sondern asynchron auf dem Server (eigene Anwendung).

[Dejan Vu]

Zitat von Sir Rufo:

In solchen Fällen kann es auch helfen, wenn man mit temporären Tabellen arbeitet.

Ja, aber imho nicht bei diesem Problem.

Zitat:

...Dann lässt man diese nicht synchron am Client laufen, sondern asynchron auf dem Server (eigene Anwendung).

Yo, aber nur, wenn man das 1x pro Monat macht, imho. Ansonsten würde ich Redundanz schaffen, aka DWH: Im Kleinstformat reicht hier eine Tabelle 'Bestellbestand' mit den Spalten der gewünschten Ausgabe und täglicher Pflege über einen Mitternachtslauf oder real-time über Trigger. Hier würde ich jedoch sogar eine Historie anlegen, mit den Spalten 'Datum, Artikel, Zeitraum, Bestand'. 'Datum' ist das heutige Datum, 'Zeitraum' ist 'Rückstand' bzw. Monat+Jahr und 'Bestand' eben der Bestand des Zeitraums. Diese Tabelle wächst täglich. Mit ihr kann ich mir eine Historie der Bestellübersichten anschauen und z.B. einschreiten, wenn sich 'Rückstände' tendenziell erhöhen oder zukünftige Bestellbestände abnehmen...

Die o.g. Auswertung erhalte ich dann über einen PIVOT