AVG OVER ORDER BY

[dabadepdu]

Zu 3, ich versteh es so, dass es mit Zahlen geht und damit also das Datum in eine fortlaufende, zeitsynchrone Zahl gewandelt werden müsste. Z. B. Julian's he's Datum..

Was bedeutet ".. akzeptiert der Code nicht.. "

 

[IchHH]

Das stimmt soweit, dass es mit Zahlen geht. Trage ich aber ROWS RANGE 365 PRECEDING AND CURRENT ROW ein, dann geht er genau 365 Zeilen zurück. Wenn aber ein Datum mehrfach vorkommt, da unterschiedliche Belege angesprochen werden, dann fehlen mir Werte die er berücksichtigen müsste. Mit Akzeptieren meinte ich so was wie "CONVERT(numeric,DATEADD(Year,-1,Buchungsdatum))" anstatt "365 PRECEDING".

 

[akretschmer]

ja, das ist der Unterschied ROWS und RANGE ...

 

[IchHH]

Macht es Sinn eine Tabelle zu bauen die nur Material, Werk, Konto und eine Summe, die Mittels Schleife die Anzahl der Zeilen und die Summe von Wert ermittelt, Partitioniert nach Material, Werk und Konto?

 

[akretschmer]

Macht es Sinn eine Tabelle zu bauen die nur Material, Werk, Konto und eine Summe, die Mittels Schleife die Anzahl der Zeilen und die Summe von Wert ermittelt, Partitioniert nach Material, Werk und Konto?

ich versteh nicht wirklich, was Du vorhast, aber bei Partitionierung gehe ich davon aus, daß der Aufwand sich rechnen muß. Das beginnt erst, wenn die einzelnen Partitionen wenigstens einige 10 oder 100 Millionen Zeilen haben.

 

[IchHH]

Na ja ich muss es ja irgendwie hinbekommen, dass ich alle Werte die zwischen den Buchungsdatum aus der jeweiligen Zeile und den Buchungsdatum minus 1 Jahr summiert pro Zeile dargestellt bekomme. Wenn ich evtl. eine Schleife baue und sage suche nach der selben Materialnummer, Werk und Konto und schau welches Datum zwischen den gerade betrachteten Buchungsdatum und Buchungsdatum-1 Jahr liegt, dann muss ich nur noch ermitteln, wieviele Zeile musste er dafür betrachten und schon kann ich die Average selber ermitteln.

 

[IchHH]

Ich habe das Problem nun mittels Inner Join mir Referenzierung auf sich selber und dann den AVG auf Wert gelöst. Performancetechnisch ist das unterirdisch, aus Mangel an Alternativen bleibt mir jedoch nichts übrig.

 

[dabadepdu]

Mit Akzeptieren meinte ich so was wie "CONVERT(numeric,DATEADD(Year,-1,Buchungsdatum))" anstatt "365 PRECEDING".

Immer noch keine Idee, was Du mit "akzeptieren" meinst. Akzeptiert er es nicht? Dann schreib doch die Fehlermeldung!
Ich sag's noch mal, ich hab kein MS SQL und ich weiß nicht, wie es regiert.

Und vom Ansatz her sind die Schnipsel*, die Du zeigst, glaub ich nicht, das was geschehen müsste.
* Ich formulier den Hinweis noch mal anders:
Wir sind hier nicht bei Gedichtinterpretationen. Schreib einfach explizit hin, was Du tust und was die Fehlermeldung ist.

Du konvertierst nicht im Range Part, da gehört halt ne Zahl hin, wie wir festgestellt haben und nichts konvertiertes. Du konvertierst das Buchungsdatum davor im Order By, damit es zu einer Zahl wird, damit die Range Syntax in MS SQL funktioniert.
also nicht
.. ORDER BY Buchungsdatum
sondern
.. ORDER BY cast(buchungsatum as int) ' oder so

Deine 365 Tage in der Range musst Du dann entsprechend umrechnen.
Und auch hier noch mal: Ich hab kein MSSQL, aber so sollte es nach meinem Verständnis funktionieren.

 

[MDDaniel]

Ich habe das Problem nun mittels Inner Join mir Referenzierung auf sich selber und dann den AVG auf Wert gelöst. Performancetechnisch ist das unterirdisch, aus Mangel an Alternativen bleibt mir jedoch nichts übrig.

Es ist nicht klar wie du das Ergebnis einschränkst. Ist die Abfrage nur für 1 Kunden oder für alle?
Mit einer CTE kannst du wahrscheinlich auch die Performance verbessern.

Weitere Anmerkung: du schreibst du willst die Daten für das vorherige Jahr da wäre ich in Verbindung mit "between" und 365 Tage bzw. 1 Jahr vorsichtig. Z.B. vom 31.12.2022 - 31.12.2023 ist nicht das selbe wie vom 1.1.23 - 31.1.23.
Ich vermute dass du mit -12 Monaten + 1 Tag die genaueren Treffer hast, besonders bei Schaltjahren.

 

[IchHH]

Ich versuche es gerne noch einmal zu erklären.

Mit dem Code AVG() OVER (PARTION BY... ORDER BY. cast(buchungsatum as int) ROWS RANGE 365 PRECEDING AND CURRENT ROW) versucht SQL "eigentlich" einen Average über die Summe der 365 Zielen oberhalb der aktuellen Zeile, die nach Material, Werk und Konto partitioniert wird zu berechnen. Genau da liegt aber das Problem bei den 365. Wenn ich z.B. an einem Tag zwei Buchung habe müsste die Zahl schon 366 satt 365 lauten um die Werte eines Jahres zu bekommen. Das hießt der Wert müsste dynamisch ermittelt werden, weshalb ich den Code nicht verwenden kann. Hätte ich die Möglichkeit wie in PostgreSQL z.B. zu sagen "365 Days" wäre alles fein gewesen.