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 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 von hoika:

Vista kann ja noch bde.

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

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 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 von onlinekater:

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?

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 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.