Dazu kommt noch die Datenmenge.
Am Ende basieren nun beide Selects auf einem Union, was sie vermutlich gleich schnell/langsam macht.
Es fallen 2 Full Table Scans an.
Was mir noch aufgefallen ist: Das Union ohne All ist kritisch.
Logisch gesehen muss es alle Datensätze inkludieren, müsste also "union all" sein. Die konkrete Select Clause verhindert hier zwar, dass tatsächlich Unique Werte zunächst entstehen und damit gleich wieder verschluckt werden, aber eine unglückliche Umformulierung des Selectteils reicht vielleicht und man verliert unbemerkt Werte.
Mit Union All ist alles easy und man erspart der
DB noch die Unique Prüfung, gewinnt also Zeit.
Hier ist noch eine Variante, die dem ursprünglichen Vorschlag von SR etwas näher kommt, ohne Kontotabelle und ohne Union. Da also das plumpe Union fehlt, kann man sich Hoffungen machen, dass ein gezielter Zugriff auf einzelne ID oder kleine Untermengen sehr viel schneller ist, vorausgesetzt die ID Columns sind indiziert:
SQL-Code:
select coalesce(foo1.id, foo2.id) as id,
--sum( haben ) - sum( soll ) as saldo
sum(coalesce(foo1.betrag, 0)) - sum(coalesce(foo2. betrag, 0)) as saldo
from (select id1 as id, betrag from buchung
-- where id1 =2
) foo1
full outer join
(select id2 as id, betrag from buchung
-- where id2 =2
) foo2
on foo2.id = foo1.id
group by coalesce(foo1.id, foo2.id)
P.S.:Ich merke gerade, dass eine Filterung (und Indexnutzung) natürlich auch im Union möglich ist. Hab ich mich selbst überlistet. (war ja auch noch früh)