Zitat von
Bernhard Geyer:
Zitat von
Lemmy:
SPs sind grundsätzlich schneller als "alles" andere, da die SPs quasi "vorkompiliert" in der
DB gespeichert werden. Alle anderen Statements die von den Clients kommen müssen erst vom Server bearbeitet werden bis sie ausgeführt werden können.
Ein teil der Performance kann man herausholen indem man die Abfragen "preparen" läßt und jeweils nur die Parameterwerte ändert.
Jupp, denn Firebird vergisst sämtliche Infos eines Statements wenn das
Handle darauf futsch ist. Will heißen, dass eine 2. Session nicht den Ablaufplan der ersten weiternutzen kann, selbst mit exakt dem gleichen
SQL Code.
Mann muss an der Reference auf das Command festhaten und es weiterbenutzen, wenn man es schnell benötigt. (Was
IMHO den eigenen Code ganz schön zerfriemeln kann....
)
Der andere Grund warum selectable SProcs bei
FB komischerweise[1] schneller sind scheint zu sein, dass der Optimizer von
FB noch gehörig Aufholbedarf hat. Es dauert einfach zu lange bis eine Abfrage ausgeführt wird und sie wird meist nicht optimal ausgeführt. Bei SProcs scheint sich
FB mehr Mühe zu geben (da er wohl auch mehr Zeit dafür hat
)
[1]Die Art wie Daten zwischen SProc und ResultSet ausgetauscht werden ist eigentlich mit einigem Overhead verbunden, der eigentlich zu etwas langsameren Laufzeiten führen sollte. (Hoch lebe der Kunjunktiv
)