SP's <> prepared queries

[hoika]

Hallo #,

ich benutze meistens prepared queries,
wenn Daten über eine Schleife ausgelesen werden.

Vorteil:
Das Statement kann dynamisch zusammengebaut werden.

Jetzt habe ich mal eine der am meistens verwendeten Queries
in eine SP umgeschrieben.

OHA !

Das war etwa 1/3 schneller!

Wie kann das sein ?

Ich übergebe 2 Integer-Parameter und bekomme ein paar floats (double precision) zurück.

Durch das prepare wird auf der Server-Seite der Query-Plan gemerkt.

Warum ist die SP um so viel schneller.


Danke im voraus

Heiko

[Bernhard Geyer]

Bekommst Du ein Recordset von deiner SP zurück?

Falls nein, so hast Du den unterschied. Der zusammenbau eines Recordset kostet auch zeit.



Fast-Off-Topic: Du nimmst immer noch BDE? Nicht schon mal native Zugriffskomponenten probiert. Du weist ja: BDE ...

[hoika]

Hallo Bernhard,

auch die SP liefert mir ein Recordset.
OK, das wird zeilenweise ausgeliefert und nicht im Server gespeichert.

Mich hat nur der enorme Geschwindigkeitsunterschied gewundert.

Zur BDE.

jaja :) ;(

Ich habe hier eine Anwendung mit ~ 500k DB-Code.
Ist ursprünglich mit Paradox entwickelt.

In vielen Forms befinden sich also noch TTables ...;(

Ich versuche ja, davon wegzukommen,
aber das wird wohl noch ein bissel dauern.

Vista kann ja noch bde.

Was empfielst du denn für Firebird ?

Heiko

[Bernhard Geyer]

Zitat:

Zitat von hoika

auch die SP liefert mir ein Recordset.
OK, das wird zeilenweise ausgeliefert und nicht im Server gespeichert.

Ich meine ob der Recordset zum Client muss und nicht ob in der SP ein RS verwendet wird.

Zitat:

Zitat von hoika

Vista kann ja noch bde.

Kann ich nicht sagen. Und vor allem welches Vista: 32 oder 64 Bit.

Zitat:

Zitat von hoika

Was empfielst du denn für Firebird ?

Ich mach nichts mit Firebird. Meine Vermutung mit den RS dürfte aber für alle SQL-Datenbanken gelten.

[TBx]

Hallo Heiko,

für einen schnellen und einfachen Umstieg kann ich die ibobjects empfehlen.

Ansonsten sind die Zeos-Komponenten zu empfehlen.

Mein persönlicher Rat: Finger weg von IBX

Gruß

onlinekater

[Edit]man wadd Dreckfuhler [/Edit]

[hoika]

Hallo,

ibx ist schon klar (wegen der Aussage von Jeff Overcash,
keine FB-spezifischen Sachen zu unterstützen).

Bei ZEOS hört man immer mal von Problemen.

IBObjects ist Löhn-Ware ..

Ich bin ja arm ..;(

Was ist mit UIB ?
Benutzt das jemand ?


Zum Umstieg.
Ich habe schon angefangen, eine eigene Query-Komponente zu schreiben.
Zur Zeit ist sie noch direkt von der BDE-Query abgeleitet.
Das wird insofern geändert,
dass ich ne abstrakte Query habe und alle Queries (BDE, ZEOS) müssen
halt alles definieren (SQL, Open usw.)

Mein Problem ist, dass in der BDE ja noch viel mehr vorgeht (Database, Transaktionen).

Das muss ich auch implementieren.

Ziel ist, dass ich mehrere Datenbanken unterstützen kann (Oracle und MS-SQL2005).


Heiko

[TBx]

Zitat:

Zitat von hoika

Ziel ist, dass ich mehrere Datenbanken unterstützen kann (Oracle und MS-SQL2005).

womit Du automatisch wieder bei ZEOS landest.

--> Achso, Dein Ziel ist es, eine eigene Komponente zu schreiben, die das alles kann?
pfff viel viel Arbeit, da Zeos opensource ist, würde ich da mal spicken ...

Über die Probleme von Zeos kann ich selbst nichts sagen, ich arbeite hauptsächlich mit den IBObjects (noch).

Gruß

onlinekater

PS: Zur Handhabung der ZEOS-Kompos: klick

[Bernhard Geyer]

Zitat:

Zitat von onlinekater

Zitat:

Zitat von hoika

Ziel ist, dass ich mehrere Datenbanken unterstützen kann (Oracle und MS-SQL2005).

womit Du automatisch wieder bei ZEOS landest.

Und wie willst Du die SQL-Unterschiede mit ZEOS handhaben? :gruebel:

WEnn Du wirklich mehrerr DB's unterstützen mußt, so empfehle ich dir eine Kapslung z.B. mit dem Bridge-Pattern.
Damit ist dir auch egal mit was für Komponenten du auf die DB's zugreifst. Sei es nun ZEOS für alle oder für jede DB eine andere.

Vorteil ZEOS:
- Exe kleiner
- Nur in eine Komponente einarbeiten nötig

Nachteile ZEOS:
- U.U. Nicht maximale Performance möglich
- DB-Spezialitäten werden nicht optimale unterstützt

[hoika]

Hallo Bernhard,

DB-Spezifische Sachen werden nicht unterstützt ?
Oha.

Wenn ich ZEOS benutze und für jede DB verschiedene Queries
benutze, sollte das doch gehen ?

Ein einfaches Beispiel wäre das Ermitteln,
ob ein Feld in einer Tabelle bereits existiert
über die Metadaten.

Ich würde also ZEOS als Query benutzen,
aber pro DB immer noch (u.U.) verschiedene Statements schicken.


Heiko

[Bernhard Geyer]

Zitat:

Zitat von hoika

Ich würde also ZEOS als Query benutzen,
aber pro DB immer noch (u.U.) verschiedene Statements schicken.

Und wo willst Du das machen? Verrteilt in deinem Programm in den Entsprechenden Units jeweils das SQL-Statement zusammenbauen?

Wenn Du das o.g. Pattern verwendest wird der DB-Unterschiedliche Teil in einer Unit/Klasse gekapselt. Aber dazu muß man nicht mehr (man kann) Zeos verwende.

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