Daten am Client sortieren ?

[erich.wanker]

Hallo Leute..

hab mal eine Grundlegende Frage:

Alle SQL Abfragen, die ein Query sendet gehen (vereinfacht gesehen) meines Verständnisses nach:
Query <-> lokalen fbguard.exe <-> tcp IP port 3050 <-> server fbserver.exe <-> Database.fdb
werden dort bearbeitet und wieder retour geschickt ...

Wenn ich nun beim Client "Sortieren nach" anklicke, hab ich bis dato immer das SQL-Statement verändert und hab vom Server die Daten in der gewünschten reihenfolge bekommen...

Ist es möglich, da man ja die Datenmänge schon lokal am client hat, diese zu sortieren ohne eine erneute SQL Abfrage zu senden .. oder gibts da probleme mit dem Datenbankzeiger ?

Vielen Dank
Erich

[grl]

Zitat von erich.wanker:

Alle SQL Abfragen, die ein Query sendet gehen (vereinfacht gesehen) meines Verständnisses nach:
Query <-> lokalen fbguard.exe <-> tcp IP port 3050 <-> server fbserver.exe <-> Database.fdb
werden dort bearbeitet und wieder retour geschickt ...

Nein.

Query <-> fbclient.dll <-> tcp IP port 3050 <-> server fbserver.exe <-> Database.fdb

Die fbguard.exe bewacht nur den fbserver-Prozess (um ihn z.B. neu zu starten) hat aber mit deinen Daten nix zu tun.

Zitat von erich.wanker:

Wenn ich nun beim Client "Sortieren nach" anklicke, hab ich bis dato immer das SQL-Statement verändert und hab vom Server die Daten in der gewünschten reihenfolge bekommen...

Ist es möglich, da man ja die Datenmänge schon lokal am client hat, diese zu sortieren ohne eine erneute SQL Abfrage zu senden .. oder gibts da probleme mit dem Datenbankzeiger ?

Nicht mit "Bordmitteln" der Datenbank. Es gibt z.B. Grid-Komponenten die das können - auch wenn ich sowas noch nie verwendet habe. Ich denke, solche Sortieraufgaben sollten immer direkt via SQL gelöst werden. Gute Komponenten nehmen dir das ab, aber sie tun auch nix anderes als die SQL-Query die beim Server ankommt anzupassen.

Gruß
Luggi

[Lemmy]

Hallo,
eine Möglichkeit wäre, das Ergebnis der Abfrage in ein TClientDataSet zu packen, dann könntest Du dort filtern und imho auch sortieren.

Grüße

[p80286]

Zitat von erich.wanker:

Ist es möglich, da man ja die Datenmänge schon lokal am client hat, diese zu sortieren ohne eine erneute SQL Abfrage zu senden .. oder gibts da probleme mit dem Datenbankzeiger ?

Das Ergebnis einer Query hat mit der liefernden Datenbank nichts mehr zu tun.

Wenn Du auf Grund der erhaltenen Information Modifikationen in der Datenbank vornehmen willst solltest Du dies nach Möglichkeit über die hoffentlich vorhandenen (primary)Keys machen.
etwa so:

Delphi-Quellcode:

select Name,strasse,ort,adrid from name,adresse where ....;

update adresse set strasse='Hinten am wald' where adrid=012345;

Gruß
K-H

[erich.wanker]

Danke für die Antworten.

Eindeutige ID´s hab ich betreffend update ..

Betreffend "TClientDataSet":

Ein TZQuery (ZEOS Lib) besitzt Eigenschaften:

• SortedField
• SortTypes
• Filter
• Filtred

Wenn ich nun ein TZQuery.sql erzeuge: (xxxx und yyy werden per code definiert..)
SELECT name, strasse FROM adressen WHERE name = "xxxx" ORDER BY yyy

und die Daten in einem Grid darstelle und nun die Sortierreihenfolge ändern will oder nur eine Teilmenge der (bereits selektierten)Daten darstellen möchte - könnte ich

A. Ein angepasstes SQL Statement abschicken ..
B. Die Funktionen vom TZQuery verwenden ..SortedField, SortTypes, Filter, Filtred ....

Kann man sagen: Solange "nur" Daten betrachtet werden (nicht neu,editieren,löschen..) sollte man die Filter und Sortierreihenfolgen vom TZQuery verwenden .. und wenn neu,editiert oder gelöscht wird sollte man mit SQL Statemnets arbeiten ... ?

Vielen Dank
Erich

[p80286]

Ich arbeite immer mit einer angepassten Query.
(nachdem ich mal Daten so durch die Mühle gedreht hatte, daß kein Bezug mehr zu den Originaldaten herstellbar war)

Gruß
K-H

[Furtbichler]

Zitat von grl:

Ich denke, solche Sortieraufgaben sollten immer direkt via SQL gelöst werden.

Gerade eben nicht. Das RDBMS ist nicht zum Sortieren da, das kostet nämlich CPU. Da die sortierte Darstellung eine Sache des Front-Ends ist, ist eben deses auch dafür zuständig. Wenn das blöde DB-Grid das nicht kann, dann muss vielleicht doch eine andere Komponente her.

Zitat:

Gute Komponenten nehmen dir das ab, aber sie tun auch nix anderes als die SQL-Query die beim Server ankommt anzupassen.

Gute Komponenten verfolgen das von mir skizzierte Ziel und sortieren in-Memory. Das geht eh schneller.

Aber die 'Billig-Variante', also Anpassen der 'ORDER BY' Klausel ist bei Datenbanken, die eh nix zu tun haben, zu verschmerzen.

[tsteinmaurer]

Hallo Erich,

client-seitiges In-Memory Sorting macht definitiv Sinn. Kommt halt darauf an, wie smart die verwendeten Komponenten (TDataset-Derivat bzw. auch Grid) sind und wie akkurat das Ergebnis sein muss. Reicht es z.b. aus, dass das Sortieren nur für bereits gefetchte Datensätze erfolgen kann, dann braucht man nicht nochmal zum Server gehen. Reicht das nicht aus, dann muss man entweder ein SELECT mit einem geänderten ORDER BY absetzen oder die Komponenten müssen zuerst alle Datensätze zum Client bringen. Gepuffert kann dann auch an unterschiedlichen Stellen werden, so z.b. beim TDataset-Derivat und/oder das Grid selbst kann auch nochmal puffern. Kommt halt darauf an, welche Komponenten zum Einsatz kommen.

Wenn du dir nicht sicher bist, wann/was zum Server geht, dann würde ich dir raten ein Monitoring dazwischen zu schalten. Vielleicht hat ja ZEOS eine Monitoring Komponente, die dir da weiterhelft. Mit Firebird 2.5 kann man das auch mit der Trace API und optional dazu mit http://www.upscene.com/products.fbtm.index.php entkoppelter vom Client und den verwendeten Zugriffskomponenten machen.

[Furtbichler]

Wenn man Sortierung auch für sehr große Tabellen anbietet, muss man serverseitig sortieren und(!) sich darauf gefasst machen, das das trotzdem verdammt lange dauern kann. Bei MSSQL ist es mW nach so, das nur die Sortierung nach einer Spalte, auf die ein 'clustered Index' liegt, ohne Zeitverlust funktioniert, bei allen anderen dauert es länger. Und tötlich ist es ohne Index.

Man muss ausprobieren, ob diese Funktionalität dann wirklich Sinn macht.

Aber bei so bis max. 5000 Datensätzen (Pi x Daumen) sollte man die Daten in den Client ziehen und dort sortieren.

[tsteinmaurer]

Zitat:

Und tötlich ist es ohne Index

Das würde ich zumindest für Firebird nicht unterschreiben.

Man hat vielleicht mal schnell das sortierte Ergebnis für die ersten Datensätze da, wenn ein Index für die Sortierung verwendet wird, aber so kann das schon mal langsamer als eine Kombination aus Non-Indexed Read + Firebird In-Memory Sort werden, wenn man alle Datensätze abholt.

Der Ausführungsplan gibt darüber Auskunft, ob In-Memory Sort order Indexbasiert und dann sieht man sich am Besten die Ausführungszeit in Kombination mit einem Fetch-All an, oder halt auch gewrappt in etwa:

Code:

SELECT COUNT (*) FROM (
  <eigentliches SELECT mit ORDER BY hier>
)