Kann man sicher auch besser machen und anders optimieren, aber eben der extremst große und bis jetzt unbekannte zeitfaktor war eben das FireBird beim GroupBy keinen Index verwenden kann.
Und die 800.000 Datensätze in ein paar Jahre dann 8.000.000 werden usw.
Aber es wurde ja schon ein WorkAround genanntm zumindest solange bis FireBird das hoffentlich irgendwann mal optimieren kann
Also was die Optimierbarkeit angeht würde ich mir nicht allzuviel Hoffnungen machen. Das ist ein systematisches Problem was mehr oder weniger zu einem Fullscan führt. Bei Optimierung vielleicht mal eines Tages ein Rangescan oder so.
Wie Du selbst schreibst, skaliert die Lösung nicht und Du weißt schon jetzt, dass Dein Problem mit der "Lösung" Fullscan von Jahr zu Jahr größer wird (oder Tag zu Tag).
Hier muss die Last anders abgefangen werden, um zu einer dauerhaften, skalierenden Lösung zu kommen. Das ist wie bereits geschrieben die denormalisierte Ablage der benötigten Infos oder wenigstens von Hilfswerten.
Bei Denormalisierung wiederum ist dringend zu empfehlen, den Speichervorgang (insert & update) so durch geeignete Datenbankconstraint zu flankieren, dass nieniemals Differenzen in den denormalisiert abgelegten Daten entstehen können(Datenkonsistenz!). Das kann
FB mit Sicherheit.
Auf diese Art (Denormalisierung) wird die Last der Abfrage verschoben auf den Zeitpunkt der "Datenentstehung". Sprich die Abfrage wird schneller, der Preis ist langsameres speichern (was aber seltener und gezielter stattfindet).