[SQL] Wie Gruppensumme bilden?

[IBExpert]

Zitat von mkinzler:

In Form einer SP/einem Codeblock:

SQL-Code:

...for select
  substring(vp.ArtikelNr from 1 for 5),
  vp.ArtikelNr,
  max(vp.Beschreibung) as Beschreibung,
  max(vp.Farbe) as Farbe,
  sum(vp.Menge) as Menge,
  sum(vp.NettoSumme) as NettoSumme
from 
  VorgangPos vp 
  into :gruppe, ArtikelNr, :... do
begin
  for select sum(Menge) from VorgangPos where substring(ArtikelNr from 1 for 5)  = Gruppe into :Gruppenmenge do suspend;
end

Der Vorschlag von mkinzler ist der einzige, der dich weiter bringen wird, weil nur der genau die Anzahl der Records im Resultset benutzt, um damit den inneren sum befehl für jedes ergebnis genau ein mal ausführt.

Wenn dein äußeres Statement schnell ist, bekommst du auf den Weg die garantie, das dein inneres Statement genau n mal aufgerufen wird. mit dem debugger in ibexpert kannst du dann sogar noch die genauen laufzeiten der einzelaufrufe ermitteln und optimieren, weil evtl genau ein artikel 99% der zeit verbraucht, das wird dir aber mit deinem wild verschachtelten sql niemals klar sein.

Es geht dann weiter mit einem Expression index auf substring(ArtikelNr from 1 for 5) und einem doppeltpunkt vor der Gruppe ( substring(ArtikelNr from 1 for 5) = :Gruppe) damit die variable auch die ist die von oben kommt (das hätte mkinzler aber auch da gesetzt, wenn es darum geht, nicht mal eben nur eine hilfreiches Beispiel hier reinzutippen, sondern das in der relaen Datenbank auszuführen).

wenn du keine sp willst, dann mach das als execute block

Firebird kann zwar with und andere konstruktionen wie subselects etc, aber vermutlich wird dir dabei in ibexpert services-database monitoring das statements mit milliarden indexed oder non indexed reads um die ohren fliegen, sonst wäre das nicht so lahm

und bitte nicht immer "andere server können das alles ganz toll mit ..."
das bringt niemanden wirklich weiter, der das mit firebird lösen soll.

ziel sollte es bei jeder Programmierung sein, mit einem jederzeit nachvollziehbaren Statement ein möglichst performantes statements zu erreichen. Und der weg, die ebenen in einem block oder einer sp mit leicht verständlichen unteraufrufen zu implementieren sorgt für gutes Verständnis des Codes, auch wenn du dir den Kram selber in 5 Jahren noch mal anschauen musst.

Ich kann dir gerne das SQL von einem Kunden zu analyse übergeben, besteht aus ca 400 Zeilen und ergibt folgende Performance Analysis
(ist auch ziemlich verschachtelt, läuft aber trotzdem in ca 0,1 sekunden durch, aber leider nur ohne fetchall, dann brauch das immer noch
vertretbare 4 minuten für ein resultset von ca 1mio records und auf dem weg dahin ca 25mio indexed reads und 1 mio non indexed reads.
Selbst ich kann dafür nicht abschätzen ob ich eine stunde, ein Tag oder eine Woche brauche, um den Speed deutlich zu verbessern
weil der SQL Basiscode nicht von mir stammt, und weil der Kunde den sql nur ein mal am tag braucht, muss das auch niemand beschleunigen,
aber bei anderen Statements kann das ganz anders aussehen.

Code:

Plan
PLAN (S POL INDEX (FK_PAYMENT_ORDER_LINE_1))
PLAN JOIN (S CH INDEX (IX_CALC_HEADER_DOC_ID), S VE INDEX (PVE_CALC_HEADER))
PLAN (A2 INDEX (ACTIONS_ACTION_ID))
PLAN (A INDEX (PK_ACTIONS))
PLAN (RH INDEX (RDB$PRIMARY12))
PLAN (A INDEX (PK_ACTIONS))
PLAN (RH INDEX (RDB$PRIMARY12))
PLAN JOIN (JOIN (JOIN (JOIN (JOIN (JOIN (JOIN (JOIN (JOIN (JOIN (JOIN (JOIN (JOIN (JOIN (JOIN (JOIN (JOIN (JOIN (JOIN (JOIN (JOIN (JOIN (S A NATURAL, S AD INDEX (PK_ADRESS)), S CO INDEX (RDB$PRIMARY5)), S VR INDEX (RDB$PRIMARY35)), S F INDEX (PK_FILES)), S FD INDEX (PK_FILE_DETAILS)), S VR2 INDEX (RDB$PRIMARY35)), S U INDEX (RDB$PRIMARY17)), S PP INDEX (RDB$PRIMARY56)), S Q INDEX (POOL_QUOTATION_QUOTATION_NO)), S Q2 INDEX (RDB$PRIMARY59)), S C INDEX (RDB$PRIMARY4)), S AST INDEX (APPLICATION_SETUP_LOCATION)), S CN INDEX (RDB$PRIMARY23)), S POH INDEX (PAYMENT_ORDER_NO)), S A2 INDEX (ACTIONS_ACTION_ID)), S PP2 INDEX (RDB$PRIMARY56)), S Q3 INDEX (POOL_QUOTATION_QUOTATION_NO)), S F2 INDEX (PK_FILES)), S FD2 INDEX (PK_FILE_DETAILS)), S VR3 INDEX (RDB$PRIMARY35)), S COM INDEX (RDB$PRIMARY4)), S APS INDEX (APPLICATION_SETUP_LOCATION))

Adapted Plan
PLAN (S POL INDEX (FK_PAYMENT_ORDER_LINE_1))
PLAN JOIN (S CH INDEX (IX_CALC_HEADER_DOC_ID), S VE INDEX (PVE_CALC_HEADER))
PLAN (A2 INDEX (ACTIONS_ACTION_ID))
PLAN (A INDEX (PK_ACTIONS))
PLAN (RH INDEX (INTEG_44))
PLAN (A INDEX (PK_ACTIONS))
PLAN (RH INDEX (INTEG_44))
PLAN JOIN (JOIN (JOIN (JOIN (JOIN (JOIN (JOIN (JOIN (JOIN (JOIN (JOIN (JOIN (JOIN (JOIN (JOIN (JOIN (JOIN (JOIN (JOIN (JOIN (JOIN (JOIN (S A NATURAL, S AD INDEX (PK_ADRESS)), S CO INDEX (PK_CONTACTS)), S VR INDEX (INTEG_184)), S F INDEX (PK_FILES)), S FD INDEX (PK_FILE_DETAILS)), S VR2 INDEX (INTEG_184)), S U INDEX (PK_USERS)), S PP INDEX (PK_CONTACTS6)), S Q INDEX (POOL_QUOTATION_QUOTATION_NO)), S Q2 INDEX (PK_CONTACTS9)), S C INDEX (PK_COMPANY)), S AST INDEX (APPLICATION_SETUP_LOCATION)), S CN INDEX (INTEG_164)), S POH INDEX (PAYMENT_ORDER_NO)), S A2 INDEX (ACTIONS_ACTION_ID)), S PP2 INDEX (PK_CONTACTS6)), S Q3 INDEX (POOL_QUOTATION_QUOTATION_NO)), S F2 INDEX (PK_FILES)), S FD2 INDEX (PK_FILE_DETAILS)), S VR3 INDEX (INTEG_184)), S COM INDEX (PK_COMPANY)), S APS INDEX (APPLICATION_SETUP_LOCATION))

------ Performance info ------  ohne fetchall
Prepare time = 31ms
Execute time = 63ms
Avg fetch time = 2,17 ms
Current memory = 89.204.432
Max memory = 89.262.048
Memory buffers = 20.000
Reads from disk to cache = 155
Writes from cache to disk = 0
Fetches from cache = 5.400

------ Performance info ------ mit fetchall
Prepare time = 16ms
Execute time = 4m 19s 750ms
Avg fetch time = 0,28 ms
Current memory = 89.283.648
Max memory = 90.161.856
Memory buffers = 20.000
Reads from disk to cache = 221.092
Writes from cache to disk = 1
Fetches from cache = 87.363.844