ZEOS MySQL-Aufbau Richtig oder Falsch??
Jens Kulenkamp
ich beschäftige mich gerade mit MySQL und verwende unter Delphi die
ZEOS-Kompo. In meinem Programm habe ich ein Connection und drei Query´s
schön in einem Datenmodul verpackt untergebracht. Auf weitere DB-Komponenten
habe ich verzichtet. Die Darstellung findet in ganz normalen Standard
Kompo´s wie TEdit, StringGrid und Comboboxen statt.
Ich hätte heirzu ein paar Fragen:
(1) Was ist der unterschied zwischen Query.open/close und Query.active :=
true/false??
(2) Die sind Query´s.active habe ich Default mässig auf false gesetzt. Wenn
eine Anfrage an den SQL-Server ansteht wird Weise ich dem Query.SQL.Text den
sql Befefehl zu, (hierbei verwende ich parameter gut oder schlecht?) mach
ein open und frage die ergebnisse ab. Zum Abschluss wieder ein Close.Wenn
nun eine zweite Abfrage ansteht: wird der SQL.Text ausgetauscht entsprechend
die Parameter gesetzt, open, abfrage der ergebnisse und ein close.
Soweit so gut oder absoluter ....? Sollte ich besser für jeden Befehl ein
eigenes Query verwenden? Das würde ein wahnsinnig grossses DM werden.
Ist das arbeiten mit den Standard Kompo´s rechenintensiver als mit
db-kompo´s?
Ich mache mir nähmlich gedanken ob die oben beschriebene Lösung überhaupt
performant ist oder ob ich mir eine andere Vorgensweise überlegen muss. Denn
bei grösseren Tabelle (im Client) bestehend aus mehreren Tabellen aus der
DB, braucht die Abfrage schon relativ lange und das wo die DB noch lokal auf
meinem Rechner installiert ist. Wie soll das bloss sein wenn ich den ersten
Test übers Netz mache ;-))
(3) Wie ist das handling, wenn ein Fehler auftritt. Ich will meine ganzen
Abfragen in ein try Except Block verpacken. Richtig oder gibts bessere
Vorgehensweisen?
Gruss Jens K.
Lothar Armbruester
> Hi NG;
>
Hallo Jens!
[...]
>
> Ich hätte heirzu ein paar Fragen:
>
> (1) Was ist der unterschied zwischen Query.open/close und Query.active
> :=
> true/false??
>
Das macht keinen Unterschied. Wenn man in den Source der Kompenenten
schaut, sieht man, dass Open intern auch nur Active auf TRUE setzt.
Die eigentliche Arbeit macht dann die SetActive-Methode.
> (2) Die sind Query´s.active habe ich Default mässig auf false gesetzt.
> Wenn
> eine Anfrage an den SQL-Server ansteht wird Weise ich dem
> Query.SQL.Text den
> sql Befefehl zu, (hierbei verwende ich parameter gut oder schlecht?)
> mach
Parameter sind an sich sinnvoll, wenn Du einen SQL mit verschiedenenen
Parametern aufrufst. Dann sparst Du Dir evtl. zusätzliche Parsing-Zeit,
weil der SQL nur wegen der neuen Parameter nicht mehr geparst wird.
(Siehe auch "Prepare" in der OH)
> ein open und frage die ergebnisse ab. Zum Abschluss wieder ein
> Close.Wenn
> nun eine zweite Abfrage ansteht: wird der SQL.Text ausgetauscht
> entsprechend
> die Parameter gesetzt, open, abfrage der ergebnisse und ein close.
>
> Soweit so gut oder absoluter ....? Sollte ich besser für jeden Befehl
> ein
> eigenes Query verwenden? Das würde ein wahnsinnig grossses DM werden.
>
SQLs, die Du häufiger mit verschiedenen Parametern aufrufst, lohnen eine
eigene Query. (s.o.)
> Ist das arbeiten mit den Standard Kompo´s rechenintensiver als mit
> db-kompo´s?
>
Ich würde nich sagen rechenintensiver, eher tippintensiver, weil Du
das Füllen der Edits selbst machen musst.
> Ich mache mir nähmlich gedanken ob die oben beschriebene Lösung
> überhaupt
> performant ist oder ob ich mir eine andere Vorgensweise überlegen
> muss. Denn
> bei grösseren Tabelle (im Client) bestehend aus mehreren Tabellen aus
> der
> DB, braucht die Abfrage schon relativ lange und das wo die DB noch
> lokal auf
> meinem Rechner installiert ist. Wie soll das bloss sein wenn ich den
> ersten
> Test übers Netz mache ;-))
>
Hier helfen Indexe, die Abfragen zu beschleunigen. Wenn die Spalten über
die auf eine Tabelle zugegriffen werden, indiziert sind, steigt die
Performance dramatisch an.
> (3) Wie ist das handling, wenn ein Fehler auftritt. Ich will meine
> ganzen
> Abfragen in ein try Except Block verpacken. Richtig oder gibts bessere
> Vorgehensweisen?
>
Das ist in jedem Fall sinnvoll.
HTH,
Lothar
--
Lothar Armbrüster | l...@oktagramm.de
Hauptstr. 26 | l...@heptagramm.de
D-65346 Eltville | lothar.ar...@t-online.de
Heiko Baumann
>
> (1) Was ist der unterschied zwischen Query.open/close und Query.active :=
> true/false??
>
kein richtig befriedigendes Ergebnis gekommen...
> Sollte ich besser für jeden Befehl ein
> eigenes Query verwenden? Das würde ein wahnsinnig grossses DM werden.
>
Ich denke das ist eine Frage deiner Programmanforderungen. Wenn du die
Ergebnisse deiner Query nur einmal sofort nach Abfrage benötigst und dann
nicht mehr, kannst du die sicher mehrfach verwenden. Brauchst du die Daten
später oder willst du damit besonderes anfangen (Formatierung etc), wäre
eine eigene Query mit evtl. persistenten Feldern sinnvoll.
> Ist das arbeiten mit den Standard Kompo´s rechenintensiver als mit
> db-kompo´s?
Bin bis auf die DB-Lookup-Kompos prima mit den DB-Komponenten gefahren. Aber
eine Antwort darauf vermag ich dir nicht zu geben - sieh doch einfach in den
Quelltexten z.B. der RxLib nach, wie die ihre RxDBComboBox basteln ;-)
> Denn
> bei grösseren Tabelle (im Client) bestehend aus mehreren Tabellen aus der
> DB, braucht die Abfrage schon relativ lange und das wo die DB noch lokal
auf
> meinem Rechner installiert ist. Wie soll das bloss sein wenn ich den
ersten
> Test übers Netz mache ;-))
>
Also das wundert mich - was ist "relativ lange"? Hab ich bisher noch nicht
erlebt, lokal superschnell und über's Netz eben so schnell wie es das Netz
hergibt. Dieser Punkt ist schon öfter hier angesprochen worden - wenn du
deine Queries dauernd öffnest und schließt und die Ergebnismenge dabei recht
gross (sagen wir mal ein "select * from... mit Hunderten von Datensätzen -
OK, Extrembeispiel *g*) ist klar, dass da viel sinnlos hin- und
hergeschaufelt wird. Also darauf achten, WAS wirklich in der Query abgefragt
werden muss und wo es nicht evtl. sinnvoller ist, die Daten einmal am Anfang
in den Speicher des Client zu blasen...
> (3) Wie ist das handling, wenn ein Fehler auftritt. Ich will meine ganzen
> Abfragen in ein try Except Block verpacken. Richtig oder gibts bessere
> Vorgehensweisen?
Keine Ahnung, aber das geht bestens und erscheint mir der richtige Weg zu
sein.
HTH, Heiko (der im Prinzip die gleichen Überlegungen wie du schon mal
angestellt hat *g*)
Thomas G. Liesner
> Hi Jens...
>> (1) Was ist der unterschied zwischen Query.open/close und Query.active :=
>> true/false??
> Hab ich mir schon auch öfter überlegt und soweit ich mich erinnern kann auf
> kein richtig befriedigendes Ergebnis gekommen...
open/close ist lesbar und active eignet sich gut zur Frage des Ist-
Zustandes.
So long,
Thomas G. Liesner
Jens Kulenkamp
"Lothar Armbruester" <lothar.ar...@t-online.de> schrieb im Newsbeitrag
news:PM00039CA...@hades.none.local...
Jens Kulenkamp
"Heiko Baumann" <bauman...@web.de> schrieb im Newsbeitrag
news:a7avm7$23k$05$1...@news.t-online.com...