Vorteile von FetchAll beim Filtern?

[Errraddicator]

Hiho!

Hab da eigentlich nur ma ne generelle Anfrage zum Nutzen von FetchAll.
So, in der Beschreibung steht ja, dass FetchAll alle Datensätze in den Speicher lädt und an sonsten jedes Mal eine neue Kommunikation mit dem Server statt findet?

Wenn ich jetzt also ein TQuery-Objekt habe, was eine große Tabelle lädt, welche ich anschließend filtere (immer nur lesend wohlgemerkt):
Würde es mir Geschwindigkeitsmäßig was nutzen, vorher ein FetchAll zu machen, damit das Filtern schneller geht?


Danke im voraus

cu Patrick

[mkinzler]

Noch besser wäre ein Serverseitiger Filter ( als Where-Clause)

[Errraddicator]

Zitat:

Zitat von mkinzler

Noch besser wäre ein Serverseitiger Filter ( als Where-Clause)

Dann müsste ich aber doch quasi jedes Mal aufs Neue eine Abfrage mit neuer Where-Klausel abschicken, oder?

Sprich:
WHERE firma=1 and Personal=1
...firma1 and Personal=2
...firma=2 and personal=10
etc. pp.

Das hatte ich schomma probiert, ist im Endeffekt langsamer, als wenn ich Anfangs alle Firmen lade und dann diese via Filter "durchsuche".
Selbst wenn ich je Firma 1 Abfrage erstelle und diese dann via Filter nach Personalnummern suchen lasse, ist das langsamer.
(Also als ne Art Mischmodus)

Von daher hat bei mir die Erfahrung gezeigt, dass in solchen Fällen das Laden und anschließende Filtern am effektivsten ist.

...

Deiner Aussage nach entnehme ich aber, dass ein FetchAll tatsächlich Geschwindigkeitsvorteile gegenüber einem Nicht-Fetch-All bringt, oder?

[mkinzler]

Zitat:

Dann müsste ich aber doch quasi jedes Mal aufs Neue eine Abfrage mit neuer Where-Klausel abschicken, oder?

Oder eine parametrisierte/prepared Abfrage verwenden dann sind nur die neuen Parameter von Nöten

Zitat:

Das hatte ich schomma probiert, ist im Endeffekt langsamer, als wenn ich Anfangs alle Firmen lade und dann diese via Filter "durchsuche".
Selbst wenn ich je Firma 1 Abfrage erstelle und diese dann via Filter nach Personalnummern suchen lasse, ist das langsamer.
(Also als ne Art Mischmodus)

Kommt auch darauf an, was du unter groß verstehst. Bei einer richtig großen Tabelle ist ein Where auf jeden Fall besser

Zitat:

Deiner Aussage nach entnehme ich aber, dass ein FetchAll tatsächlich Geschwindigkeitsvorteile gegenüber einem Nicht-Fetch-All bringt, oder?

Sollte

[Errraddicator]

Also bei meinem jetztigen Programm hält sich das in Grenzen von der Datenmenge, da hab ich so zwischen 1.000 und 30.000 Sätze pro Select-Anfrage, welche ausgewertet werden möchte.

In einem Anderen Programm (deswegen frage ich hauptsächlich) kann das aber schomma durchaus in die 50 bis 100.000 oder mehr Sätze Region gehen und da ist das Tempo dann schon ein wichtiges Argument!

...

Wie genau muss ich mir das mit den Prepared-Statements denn vorstellen?
Das sagt mir jetzt ma so gar nix *schäm*

[Bernhard Geyer]

Zitat:

Zitat von Errraddicator

Das hatte ich schomma probiert, ist im Endeffekt langsamer, als wenn ich Anfangs alle Firmen lade und dann diese via Filter "durchsuche".

Solange dien Tabelle "Übersichtlich" ist mag das stimmen. Aber wenn sehr viele Datensätze in dieser Tabelle sind wir dier Erstladung schon Problematisch.
(z.B Sozialkasse mit 80 Mio. Datensätze von Bundesbürgern)

Zitat:

Zitat von Errraddicator

Selbst wenn ich je Firma 1 Abfrage erstelle und diese dann via Filter nach Personalnummern suchen lasse, ist das langsamer.
(Also als ne Art Mischmodus)

Schon mal mit prepared Statements gearbeitet?

Zitat:

Zitat von Errraddicator

Deiner Aussage nach entnehme ich aber, dass ein FetchAll tatsächlich Geschwindigkeitsvorteile gegenüber einem Nicht-Fetch-All bringt, oder?

Je nachdem. Bei Gridanzeige ist Nicht-Fetch-All besser (schnelleres erstes Anzeigen). Wenn man aber eh sofort alle Datensätze benötig ist das sofortige Fetchen besser.

[mkinzler]

Vorbereiten:

Delphi-Quellcode:

Query.Sql.Text := 'select ... from ... where firma=:firma and Personal=:personal;';
Query.Prepare;

...

Die eigentlich Abfrage:

Delphi-Quellcode:

Query.ParamByName('firma').Value := 1;
Query.ParamByName('personal').Value := 1;
Query.Open; //bzw. Refresh;

[Errraddicator]

Ok, probiere ich ma aus mit dem Prepared-Gedöhne.

Wie muss ich mir das denn technisch vorstellen, also was passiert da (so grob).
Damit ich zumindest nen Hauch von Hintergrundwissen hab. :D

[mkinzler]

Das Statement wird vom DBMS geparst, ein Zugriffsplan erstellt und dieser je nach DBMS noch optimiert.
Später werden die Parameter auf diesen angewendet

[Errraddicator]

Hab jetzt ma nen bissel rumgespielt und festgestellt, dass für meine Bedürfnisse ne Mischung aus beidem am besten funzt.
Also sowohl Filter nutzen als auch die "großen" Abfragen vorher via Prepare vorbereiten.

Falls es wen interessiert hier meine Zeitmessungen:

Zitat:

Programm A
---
1 große Abfrage (FetchAll + Filter)
ohne Prepared: 00:00:37
mit Prepared: 00:00:19

x kleine Abfragen
ohne Prepared: 00:02:02
mit Prepared: 00:02:04


...


Programm B (hier jeweils nur 1 große Abfrage und Filter)
---
Ladezeit
ohne Prepared: 00:00:05
mit Prepared: 00:00:05

Verarbeitung
ohne Prepared: 00:04:35
mit Prepared: 00:01:54

Die Nutzung von FetchAll hat übrigens keinen Unterschied gezeigt, das ist wohl egal in meinen Fällen.

Danke für die Hilfe :)