Firebird V3.0 - Neue Aggregatfunktionen

[lowmax_5]

Hallo,

ich möchte gerne die neuen FB-Funktionen nutzen OVER/PARTITION nutzen, um Aggregatabrufe zu beschleunigen.
Die Daten befinden sich nun aber in mehreren Tabellen:

Kunden(KNr,Name)
Rechnungen (RNr,Datum, Betrag,KNr)
Auftrag (ANr,Datum,Betrag,KNr)

Als Ergebnis soll folgendes herauskommen:
KNr,Name, SumAuftragbetrag,SumRechnungBetrag,AvgRechnungBetr ag

Der Weg über 'Group by' oder dem bekannten 'inline select' ist mir klar. Nur wie lässt sich dieses mit OVER/PARTITION realisieren? Stehe gerade auf dem Schlauch....

[mkinzler]

Auf den Join anwenden. Ich bezweifle aber, das das schneller als ein Join auf die Summen wäre.

[tsteinmaurer]

Ich bezweifle, dass dir hier die neuen Aggregatsfunktionen einen Mehrwert bringen. Die Idee von diesen neuen Window Functions ist einfach gesagt die Entkopplung der GROUP BY Klausel (was eine Filterung der Datenmenge als Folge hat) von der Aggregatsbildung. In deinem Fall willst ja dann einfach eine Zeile je Kunde mit den Summen haben, oder? Hier tuts ein einfaches:

Code:

select
  k.knr
  , k.name
  , sum(a.betrag) as sum_auftragbetrag
  , sum(r.betrag) as sum_rechungbetrag
from
  kunden k
  left join AUFTRAG a on (a.KNR = k.KNR)
  left join RECHNUNGEN r on (r.KNR = k.KNR)
group by
  k.KNR
  , k.NAME

LEFT JOIN vs. INNER JOIN musst du entscheiden, ob ein Kunde ohne Auftrag bzw. Rechnung in der Ergebnismenge auftauchen soll.

LG

[lowmax_5]

Vielen Dank für die Antworten. Da hatte ich mir doch wohl ein wenig zu viel Hoffnungen in die neuen Aggregatsfunktionen gesteckt... Da sehr viele Datensätze durchgegangen werden müssen und die Performance nicht entsprechend gut ist, muss ich dann wohl konzeptionell anders vorgehen (==>OLAP).

[tsteinmaurer]

Was heißt sehr viel je Tabelle und wie lange dauert die Abfrage?

[mkinzler]

Du kannst zuerst Joinen und zusammenfassen (langsam) oder schauen, ob die zuerst zusammenfasst und dann die Daten kombinierst ( im Idealfall schneller)

[lowmax_5]

Zitat:

Was heißt sehr viel je Tabelle und wie lange dauert die Abfrage?

In der Praxis ist das Thema komplexer als in dem von mir genannten Beispiel. Innerhalb einer SP werden neben Joins auch Sub-SP's aufgerufen, um die notwenigen Daten zusammenzustellen. Die Laufzeit beträgt ca. 1 Minute aber auch mehr, wobei es auf einige Tabellen zwischen 200T und 22Mio IR's gibt. Alles ist soweit optimiert, das es nur sehr wenige NIR's gibt.

Da die Datenmenge auf jeden Fall durchlaufen werden muss, um die Werte zu ermitteln, komme ich wohl um das Thema OLAP/Aggregatstabellen nicht herum, um auch bei varierenden Fragestellungen eine AdHoc-Abfragen in einer akzeptablen Zeit beantworten zu können. Würde es hier noch andere Lösungswege geben?

[tsteinmaurer]

Zitat:

Würde es hier noch andere Lösungswege geben?

Nein. Für analytische (Ad-Hoc) Fragestellungen bei wachsendem OLTP Datenvolumen wirst in Richtung Voraggregrierung etc. gehen müssen. Wennst für das OLAP System auf Firebird oder relational bleiben willst, dann hilft dir vielleicht folgender Artikel von mir weiter: https://www.ibphoenix.com/resources/.../general/doc_1

[mkinzler]

Interessanter Artikel :thumb:

[lowmax_5]

Zitat:

Wennst für das OLAP System auf Firebird oder relational bleiben willst, dann hilft dir vielleicht folgender Artikel von mir weiter: https://www.ibphoenix.com/resources/.../general/doc_1

Das hört sich schon mal sehr gut an! Wenn ich es richtig verstehe, werden die Daten (mit einer Update-Strategie) 'vorbereitet' und in die DWH-Tabellenstruktur gepackt. Anschliessend können diese dann 'zeitnah' angerufen werden.(alles mit FB) Mondrian als OLAP-Server untersützt dabei den Anwender, die Abfragen zu generieren - es würde aber auch ohne den OLAP-Server gehen, wenn die Abfragen vorher feststehen bzw. definiert werden.
Korrigiere mich bitte, falls ich auf dem Holzweg bin ...:wink: