SQL monatliche Summierung

[alex517]

Hi,

ich verwende für solche Fälle eine Procedure die mir den Zeitstrahl
vorgibt. Damit ist keine extra Tabelle notwendig.
Damit würde deine Abfrage so aussehen

SQL-Code:

select
  JM.Jahr,
  JM.Monat,
  sum(PAYMENT) as SumPrice
from
  SP_JJMM(:VonDatum, :BisDatum) JM
  left join PAYMENTS P on (EXTRACT(YEAR from P.PAYMENT_DATE) = JM.JAHR AND EXTRACT(MONTH from P.PAYMENT_DATE) = JM.MONAT)
group BY
  JM.Jahr,
  JM.Monat

Edit: muss natürlich left join heißen..

oder so

SQL-Code:

select
  JM.Jahr,
  JM.Monat,
  sum(PAYMENT) as SumPrice
from
  SP_JJMM(:VonDatum, :BisDatum) JM
  left join PAYMENTS P on (EXTRACT(YEAR from P.PAYMENT_DATE) * 100 + EXTRACT(MONTH from P.PAYMENT_DATE) = JM.JJJMM)
group BY
  JM.Jahr,
  JM.Monat

und hier noch die SP dazu:

SQL-Code:

create or alter procedure SP_JJMM (
    ADATUM_VON date,
    ADATUM_BIS date)
returns (
    JAHR integer,
    MONAT integer,
    JJJJMM INTEGER)
as
declare variable VON integer;
declare variable BIS integer;
begin
  IF (ADATUM_VON is not NULL) THEN
    VON = EXTRACT(YEAR FROM ADATUM_VON) * 100 + EXTRACT(MONTH FROM ADATUM_VON);
  ELSE
    VON = EXTRACT(YEAR FROM CURRENT_DATE) * 100 + EXTRACT(MONTH FROM CURRENT_DATE);

  IF (ADATUM_BIS is not NULL) THEN
    BIS = EXTRACT(YEAR FROM ADATUM_BIS) * 100 + EXTRACT(MONTH FROM ADATUM_BIS);
  ELSE
    BIS = EXTRACT(YEAR FROM CURRENT_DATE) * 100 + EXTRACT(MONTH FROM CURRENT_DATE);

  JAHR = NULL;
  MONAT = NULL;

  WHILE (VON <= BIS) DO
  BEGIN
    JAHR = VON / 100;
    MONAT = MOD(VON, 12) +1;
    JJJJMM = JAHR * 100 + MONAT;
    suspend;
    VON = VON +1;
  END
end

[FredlFesl]

Wenn Du aus deiner SP eine Tabelle aller Tage seit Christi Geburt (oder weiß der Himmel :mrgreen: seit wann) machst, kannst Du zudem noch weitere Informationen dort hinein packen. Als da wären:
Name des Wochentags, Feiertage, Arbeitstage, Ferien, Bürozeiten, Mittagspausen.

Alles kann man natürlich individuell ausrechnen, das dauert aber auch...

Die Tabelle wird zwar nicht sonderlich klein sein (sagen wir: 2000x365x24 Zeilem, 20 oder so Spalten), aber WTF. Wir haben es schließlich mit einer DB zu tun, da sind die paar Zeilen ein Klacks.

Vorteil: Du kannst für jedes Projekt diese Tabelle übernehmen und musst nur geschäftslogik-spezifische Werte (Arbeitszeiten, Ferien etc.) anpassen.

[omata]

Da finde ich jobo's Ansatz ja noch besser. Naja, holt die Kanonen raus, die Spatzen sind im Anflug. (Ich bleibe lieber bei Datenmanipulation auf reinster SQL-Ebene -> kurz, einfach, einfach schön <- Geschmacksache)

[omata]

Oh, hab es erst jetzt gesehen...

Zitat:

Zitat von jobo (Beitrag 1113268)

Du sparst Dir das Jahr und implizierst in Deinem SQL, dass es in der payment Tabelle auftauchen muss?

Äh, ja, alles andere macht auch keinen Sinn.

[jobo]

Das Jahr aus der Payments Tabelle zu holen, birgt die Gefahr, dass es dort mal gar nicht drin steht. Lückenhafte Daten waren ja angesagt. Und wenn wir schon poetisch werden bei dem Thema:
Lieber ne Taube in der Hand, als ein Spatz auf dem Dach. ;)

Die Spalte mit den Jahren kann über eine separate Tabelle ebenfalls pivotisiert werden. Eine Tabelle mit 5, 10 oder50 Jahreseinträgen bietet einen definierten Rahmen, deren Kreuzprodukt mit einer Monatstabelle a 12 Sätze liefert gezielt alles was gebraucht/gewünscht ist.

Der Ansatz per Stored Proc bietet weiterhin auch die Möglichkeit, auch Daten für wöchentliche oder ander Cluster auszuspucken.

Edit meint: Hab einen Beitrag übersehen, die Lösung von Alex gefällt mir am besten

[omata]

Ich habe meinen Scheiss entfernt. Sorry, für den Spam.