SP's <> prepared queries

[hoika]

Hallo,

naja, in der Theorie klingt es immer so einfach.
Aber in der Praxis ...

Mein Problem ist, dass ich z.B. gar nicht weiss,
welche Unterschiede eine DB zu einer anderen haben kann.

Das fängt schon an mit den Platzhaltern für Parameter.

Das müßte die Query ja auch unterschiedlich zusammenbauen.

Naja,

ich versuche erst mal, von der BDE wegzukommen,
das ist schon finster genug ;(

Ich melde mich dann in 2 Jahren noch mal zu dem Thema ;)

Heiko

[Lemmy]

Hi,

ich verwende UIB, aber ausschließlich bei Server- bzw. in Mehrschichtanwendungen, da UIB kein bearbeiten des aktuellen Datensatzes in DB-Komponenten ermöglicht.

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.

Desweiteren können SPs schneller sein, da diese i.d.R. auf einem Server ausgeführt werden, welcher i.d.R. eine bessere Ausstattung an Hardware hat als ein "normaler" Client.

Lemmy

[Bernhard Geyer]

Zitat:

Zitat von hoika

naja, in der Theorie klingt es immer so einfach.
Aber in der Praxis ...

Von einfach hab ich nichts geschrieben. Man muß schon ein bischen Gehirnschmalz investieren.

Zitat:

Zitat von hoika

Mein Problem ist, dass ich z.B. gar nicht weiss,
welche Unterschiede eine DB zu einer anderen haben kann.

Das fängt schon an mit den Platzhaltern für Parameter.

Du kannst ja hier fragen. Bei ADO (Native) z.B. wird ein Fragezeichen als Platzhalter genommen

Zitat:

Zitat von hoika

ich versuche erst mal, von der BDE wegzukommen,
das ist schon finster genug ;(

Du kannst ja erst die Kapslung des DB-Zugriffs auf eine Unit/Klasse durchführen und anschließend
den DB-Wechsel mit Hilfe dieser zentralen Klasse relativ einfach erledigen.

Vorteil:
- (fast) immer Release-Fähig
- Einfacher Support mehrere DB's ist "Abfallprodukt" dieser Vorgehensweise

Zitat:

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.

[Elvis]

Zitat:

Zitat von Bernhard Geyer

Zitat:

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 :stupid: )