Performance von Datenbankabfrage

[Tobi]

Hallo,
ich moechte eine Datenbankabfrage (M$ Access) im Performance tunen....

1. Welchen Effekt hat z.B., wenn ich im SQL Statement statt SELECT * FROM ... die Wildcard durch die Namen der abzufragenden Datenbankfelder ersetze? Ist das zu empfehlen?
2. Welcher Verbindugnstyp sollte gewaehlt werden? (DNS, DNS-less, ADODB etc.)
3. Wirkt sich ein setzen von Parametern (z.B. Cursorlocation=adopenstatic, Locktype=adlockreadonly etc.) positiv aufs Performance aus?
4. Welcher Abfragetyp sollte gewaehlt werden? (recordset, getrows oder stored procedures)

Waere nett, wenn Ihr mir Tipps geben koenntet...
Gruss
Tobi

[Frank aus Ulm]

Moin :-)

1. Welchen Effekt hat z.B., wenn ich im SQL Statement statt SELECT * FROM ... die Wildcard durch die Namen der abzufragenden Datenbankfelder ersetze? Ist das zu empfehlen?

* ruft ja alle Felder auf, wenn du nicht alle Felder brauchst, dann trag dort nur die gewünschten ein -> Performancegewinn, weil ja nicht soviele Felder im Recordset gespeichert werden müssen

2. Welcher Verbindugnstyp sollte gewaehlt werden? (DNS, DNS-less, ADODB etc.)

ADODB ist kein Verbindungstyp sondern die Komponente zum Zugreifen ... ActiveX Data Objects.

DSN / DSN-less ist auch nicht so treffend ... wobei ich immer DSN-less vorziehen würde

du mußt dich zwischen OLEDB Engine (soweit verfügbar - bei Access natürlich) und ODBC layer (der aber evt. auch wieder die JET OleDB Engine benutzt) entscheiden. OleDB ist besser, da man diesen ODBC layer nicht dazwischenschalten muß

3. Wirkt sich ein setzen von Parametern (z.B. Cursorlocation=adopenstatic, Locktype=adlockreadonly etc.) positiv aufs Performance aus?

ja, ziemlich ...

wenn du nur lesen willst, recordset abrasseln und in HTML darstellen dann

adOpenForwardOnly
adLockReadOnly

wenn du Daten einfach modifizen willst, nimm connection.execute mit dem Update/Insert SQL und stelle einen Parameter auf "keine Recordsetrückgabe" (keine Ahnung wie der grad heißt)

wenn du multiple Datensatzänderungen machen willst, mehrere geöffnete Recordsets gleichzeitig, dann mußt du entscheiden, ob adOpenStatic (erzeugt einen statischen Snapshot von der DB mit deiner SQL Abfrage) oder adOpenDynamic/adOpenKeyset (erzeugen immer noch von DB seite veränderliche Recordsets (falls jemand anders grad updatet)) nehmen willst. adOpenDynamic und -keyset sind performanceintensiver

4. Welcher Abfragetyp sollte gewaehlt werden? (recordset, getrows oder stored procedures)

Wie ich ja neulich gelernt habe *grins* empfiehlt es sich, dass recordset so schnell als möglich wieder zuzumachen.

Aber die möglichkeit storedProcedures passt da nicht unbedingt hin, denn wenn du eine ausführst bekommst du fast zwangsweise auch wieder ein Recordset welches du wieder mit getRows zum Array machen könntest.

StoredProcedures haben ihren Vorteil darin, daß sie auf dem Datenbankserver vorkompiliert sind und wesentlich schneller ausgeführt werden können. Desto komplexer die Abfrage/Prozedur destomehr Performance Gain.

5. (von mir hinzugefügt)

du solltest dir auch mal gedanken machen, in access parameterisierte Abfragen zu erstellen und diese zu verwenden, das ist sicherer gegen SQL injection und vielleicht auch etwas performanter. Access Abfragen kann man aber noch lange nicht mit StoredProcedures eines SQL Servers vergleichen.

Waere nett, wenn Ihr mir Tipps geben koenntet...

bitte, gern geschehen

Tschau, tschüß,
Frank

[Tobi]

Hallo Frank,

scheinbar sind wir beiden die einzigen, die sich hier im Forum noch fuer Datenbankabfragen mit ASP interessieren. Und wie du merkst, bin ich sehr lernwillig....;o)

* ruft ja alle Felder auf, wenn du nicht alle Felder brauchst, dann trag dort nur die gewünschten ein -> Performancegewinn, weil ja nicht soviele Felder im Recordset gespeichert werden müssen

Jep, so hab ich mir das gedacht....

2. Welcher Verbindugnstyp sollte gewaehlt werden? (DNS, DNS-less, ADODB etc.)

ADODB ist kein Verbindungstyp sondern die Komponente zum Zugreifen ... ActiveX Data Objects.

DSN / DSN-less ist auch nicht so treffend ... wobei ich immer DSN-less vorziehen würde

du mußt dich zwischen OLEDB Engine (soweit verfügbar - bei Access natürlich) und ODBC layer (der aber evt. auch wieder die JET OleDB Engine benutzt) entscheiden. OleDB ist besser, da man diesen ODBC layer nicht dazwischenschalten muß

Hmmm...ja Verbindugnstyp war der falsche ausdruck dafuer, aber ich sehe Du hast verstanden was ich meine.
Ich benutze momentan DSN-less Connection und als Provider (das meinte ich natuerlich) OLEDB (jet 4.0)...das scheint also mit deiner empfehlung uebereinzustimmen.

3. Wirkt sich ein setzen von Parametern (z.B. Cursorlocation=adopenstatic, Locktype=adlockreadonly etc.) positiv aufs Performance aus?

ja, ziemlich ...

wenn du nur lesen willst, recordset abrasseln und in HTML darstellen dann
adOpenForwardOnly
adLockReadOnly

wenn du Daten einfach modifizen willst, nimm connection.execute mit dem Update/Insert SQL und stelle einen Parameter auf "keine Recordsetrückgabe" (keine Ahnung wie der grad heißt)

wenn du multiple Datensatzänderungen machen willst, mehrere geöffnete Recordsets gleichzeitig, dann mußt du entscheiden, ob adOpenStatic (erzeugt einen statischen Snapshot von der DB mit deiner SQL Abfrage) oder adOpenDynamic/adOpenKeyset (erzeugen immer noch von DB seite veränderliche Recordsets (falls jemand anders grad updatet)) nehmen willst. adOpenDynamic und -keyset sind performanceintensiver

Das war wieder sehr interessant fuer mich, leider findet man ueber ADO-Constants nur sehr wenig (auch mit google - ausser das sie existieren). Wie machst Du das eigentlich, bindest Du die kompletten ADO Konstanten als inc file ein oder nur ausgesuchte oder setzt du nur die Zahlenwerte?

4. Welcher Abfragetyp sollte gewaehlt werden? (recordset, getrows oder stored procedures)

Wie ich ja neulich gelernt habe *grins* empfiehlt es sich, dass recordset so schnell als möglich wieder zuzumachen.

Jo, hoert sich gut an, wo haste das gelernt? ;o)

Aber die möglichkeit storedProcedures passt da nicht unbedingt hin, denn wenn du eine ausführst bekommst du fast zwangsweise auch wieder ein Recordset welches du wieder mit getRows zum Array machen könntest.

Hast recht. Unklare Auflistung.

StoredProcedures haben ihren Vorteil darin, daß sie auf dem Datenbankserver vorkompiliert sind und wesentlich schneller ausgeführt werden können. Desto komplexer die Abfrage/Prozedur destomehr Performance Gain.

5. (von mir hinzugefügt)

du solltest dir auch mal gedanken machen, in access parameterisierte Abfragen zu erstellen und diese zu verwenden, das ist sicherer gegen SQL injection und vielleicht auch etwas performanter. Access Abfragen kann man aber noch lange nicht mit StoredProcedures eines SQL Servers vergleichen.

Parameteris... aha...(sowas wie stored proc?) okay, werde mich da mal eingooglen ..aeh.. -lesen. Ja und der Sicherheitsaspekt ist dann das naechste worauf ich mich stuerzen werde...(bereite Dich schon mal auf ein paar Fragen dazu im Forum vor!;o) Ich bin auch gerade dabei, mich in MySQL einzuarbeiten - auch wenn es wahrscheinlich nicht erste Wahl ist, wenn man auf Windows arbeitet (z.B. keine stored Proc), aber man muss sich ja einen Ueberblick verschaffen.

Wie wuerdest Du eine Connection mit asp zu Mysql machen? Habe mir Datenbanktreiber fuer Win runtergeladen und dann DSN-less mit ODBC - geht das auch besser mit OLEDB? Was ist bei MySQL zu beachten?

Wie immer, danke fuer Deine Hilfe & Gruss
Tobi

[Frank aus Ulm]

Hi, hallo

Hallo Frank,

scheinbar sind wir beiden die einzigen, die sich hier im Forum noch fuer Datenbankabfragen mit ASP interessieren.

sieht so aus ... :-)

Das war wieder sehr interessant fuer mich, leider findet man ueber ADO-Constants nur sehr wenig (auch mit google - ausser das sie existieren). Wie machst Du das eigentlich, bindest Du die kompletten ADO Konstanten als inc file ein oder nur ausgesuchte oder setzt du nur die Zahlenwerte?

nicht immer googeln ... auch mal die Suche von msdn.microsoft.com benutzen
da findest du 100%ig mit "adLockReadonly" das was du suchst.

es gibt bei der installation vom PWS / IIS irgendwo unter c:\inetpub eine datei namens adovbs.inc   ... da stehen alle drin. Ansonsten kann man sich auch die Zahlenwerte merken

Parameteris... aha...(sowas wie stored proc?) okay, werde mich da mal eingooglen ..aeh.. -lesen. Ja und der Sicherheitsaspekt ist dann das naechste worauf ich mich stuerzen werde...(bereite Dich schon mal auf ein paar Fragen dazu im Forum vor!;o)

tu ich doch glatt :-)

Ich bin auch gerade dabei, mich in MySQL einzuarbeiten - auch wenn es wahrscheinlich nicht erste Wahl ist, wenn man auf Windows arbeitet (z.B. keine stored Proc), aber man muss sich ja einen Ueberblick verschaffen.

Stored Procedures ist eins von vielen Mankos gegenüber ordentlichen Datenbanken (damit mein ich aber auch nicht Access)

MySQL ist (imho) was für "mittellose" Progger mit geringen Ansprüchen an Professionalität aber großer Verblendung durch OpenSource oder für profitgeile Möchtegern-Softwaredienstleister, die denken, sie könnten so doppelt verdienen. (in echt gemachte Erfahrungen in der Vergangenheit 2J). Ich muß es zwar auch benutzen aber bin 0% zufrieden. Das es im Internet so gut vertreten und so beliebt ist, ist glückssache und preissache :-)

Wie wuerdest Du eine Connection mit asp zu Mysql machen?

Wenn ich muß - weil MySQL die DB is, wo ich Daten her brauche, dann ja.

Habe mir Datenbanktreiber fuer Win runtergeladen und dann DSN-less mit ODBC - geht das auch besser mit OLEDB?

mit ist keine OleDB Engine für MySQL bekannt.

Was ist bei MySQL zu beachten?

Ziemlich anderer SQL Dialekt => nicht mal halb so gut wie Microsoft Transact-SQL, keine Beziehungen, keine Unterabfragen ... leicht andere Datentypen, proprietäres Datenbankformat.

Tschau, tschüß,
Frank

[Odium]

Hallo,

scheinbar sind wir beiden die einzigen, die sich hier im Forum noch fuer Datenbankabfragen mit ASP interessieren.

sieht so aus ... :-)

nicht ganz, ich komm auch mal wieder kucken...

Odium