SQL-Statement zu aufwendig

[DeddyH]

Wie ist es, wenn Du den Disponenten als JOIN-Bedingung hinzufügst?

[Ykcim]

Hallo,

keine Chance, der MySQL-Server kommt damit einfach nicht zurecht... Ich habe jetzt schon wieder ca. 30 min. gewartet - er ist noch nicht fertig...

Gruß
Patrick

[jobo]

Du verwendest auf einigen Spalten eine Funktion (month), um das Ergebnis mit einer weiteren Funktion zu vergleichen.
Month(currentdate) usw. sollte kein Problem sein (Kopfrechnen), sowas wie month(<spalte>) macht aber idR die (hoffentlich vorhandenen) Indices unbrauchbar.
Wenn Du das umformst nach

Code:

<spalte> between [anfang aktueller Monat] and current_date

könnte es deutlich schneller laufen.
Bevor Du nun lange bastelst, um den aktuellen Monatsanfang auszurechnen, probier es einfach mal mit festen Werten aus, vlt. "current_date - 27" (das wäre heute der 1.Mai.), ich kenne die Datumsfunktionen von mySQL leider nicht auswendig.

[himitsu]

Mal so als Tipp: Lass' alle Aggregatfunktionen (Sum) weg und auch das GroupBy muß kurz raus.
Und jetzt schau dir mal an, was deine Joints eingentlich veranstalten.
(ich glaub nicht, daß es dem entspricht, was du willst)

Im Grunde müssen die SUM-Felder also eher SubSelects sein, würde ich mir mal so denken.

PS: Als [code=sql]...[/code] macht sich der obrige "Delphi"-Code bestimmt auch viel besser.

[Dejan Vu]

Versuch es mal ganz ohne join:

SQL-Code:

select concat(watenr,' ',tebez1) as 'Artikel Bezeichnung', 
   sum(iif(ltlite < current_date, ltrest,0) as Rückstand, 
   sum(iif(month(ltlite) = month(current_date)    ,ltrest,0) as 'Bedarf aktueller Monat',
   sum(iif(month(ltlite) = month(current_date) + 1,ltrest,0) as 'Bedarf nächster Monat',
   sum(iif(month(ltlite) = month(current_date) + 2,ltrest,0) as 'Bedarf übernächster Monat'  
from liefersituation
group by concat(watenr,' ',tebez1)

Bezüglich der Syntax musst du das ggf. anpassen. Kann kein mist-QL.
Wichtig ist, das in deinem Group By- Ausdruck alle Ausdrücke angegeben sein müssen, die nicht aggregiert werden.

Das dürfte so auch mit deiner 'Month' Klausel, da er eh nur 1x durch die Tabelle rennt.

PS: Dein 'Bedarf aktueller Monat' enthält auch den Rückstand des aktuellen Monats....
also vielleicht alternativ...

SQL-Code:

...
   sum(iif(ltlite >=current_date and month(ltlite) = month(current_date)    ,ltrest,0) as 'Bedarf aktueller Monat',
...

[arnof]

Zitat von Ykcim:

Hallo,

keine Chance, der MySQL-Server kommt damit einfach nicht zurecht... Ich habe jetzt schon wieder ca. 30 min. gewartet - er ist noch nicht fertig...

Gruß
Patrick

Das nennt man dann Datenbankdesign. Zur Analyse warum da was nicht geht bzw zu langsam ist, hat emba die entsprechenden Tools.

Beispiel aus meiner Praxis: SQL Abfrage aufgrund von Datenmengen beim Kunden nicht benutzbare 30 sec, durch setzen der Indexe passend zur Abfrage auf nicht mehr fühlbare 0.01 sec reduziert ohne eine Zeile Delphicode zu ändern!

[Dejan Vu]

Meist benötigt man dazu keine Tools. Scharfes hinschauen genügt. Und wenn man etwas faul ist, scharfes Betrachten des Queryplans. Die von mir vorgeschlagene Optimierung (von der ich arroganterweise annehme, das sie eine schnellere Möglichkeit ist) bekommt ein Tool eh nicht hin. Behaupte ich mal.

Betonung allerdings auf 'meist', also für professionelle Optimierung als Lebensaufgabe oder Berufsdefinition sind solche Tools durchaus brauchbar.

[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.