Daten am Client sortieren ?

[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>
)

[jobo]

Wir arbeiten grundsätzlich mit serverseitigem Filtern und Sortieren.
In der Praxis wird eine theoretisch sehr große Datenmenge nie abgerufen, es werden immer nur die voreingestellten max records geholt, z.B. 50 von 12T Bankstammdaten. Eine korrekte Sortierung ist bei dem Verfahren nur serverseitig zu erreichen. Für Suche, Datenpflege usw. m.E. auch vollkommen ok.
Alternativ muss ich bei clientseitiger Sortierung immer(!) 12T Datensätze oder mehr runterladen, um dann richtig (also vollständig) sortieren zu können.
Ist die Frage, was mehr Stress macht, zig Tausend(e) Daten laden und sortieren oder eben 50 richtig sortierte.

Ich würde nur in Sonderfällen clientseitig sortieren.