paged query im Eigenbau?

[Sir Rufo]

@himitsu

Das kommt einfach auf die Implementierung an.

Nehmen wir mal an, der erste Zugriff erstellt aus der Abfrage eine temporäre Tabelle (auf dem Server) und holt von dort dann die erste Seite. Alle anderen Seiten werden dann nur noch aus der temporären Tabelle geladen.

Eine andere Sortierung ist auch problemlos möglich (über die temporäre Tabelle).

[Dejan Vu]

Zitat von Sir Rufo:

... Nehmen wir mal an, der erste Zugriff erstellt aus der Abfrage eine temporäre Tabelle (auf dem Server) und holt von dort dann die erste Seite. ...

Leute, wir reden hier von 100 Mio Zeilen, die möglichst schnell durchlaufen werden sollen. Glaubt ihr ernsthaft, das eine andere Lösung als 'happenweise einlesen' besser oder auch nur im Ansatz brauchbar ist?.

Das Erstellen einer mehrere GiB großen temporären Tabelle dauert ewig, weil die Daten committed werden müssen und müllen den Server zu. Mach das ein paar mal (am Besten noch gleichzeitig) und egal wie viele TB Plattenplatz du hasthattest, nu sindse weg. Und das alles nur, weil ein Programmierer die grandiose Idee hatte, eine Tabelle zu klonen, nur um in Ruhe in ihr rumscrollen zu können. Sofern die Vorgabe 'während des Rumstöberns will ich Änderungen nicht sehen' ist, könnte man noch drüber nachdenken, wobei dann ein serverseitiger Cursor mit entsprechendem Isolation Level einfacher wäre (wenn der Cursor das mit macht), aber hinsichtlich der Speicherverplemperei ebenso suboptimal.

Wir wissen ja, das rumstöbern in 100 Mio Datensätzen eh Blödsinn ist und daher muss man sich über solche Ansätze keine Gedanken machen. Wenn ich meine Daten unverändert abholen will, erstelle ich einfach einen application lock auf der Tabelle, hole das Zeugs ab und fertig ist die Laube. Es wäre vielleicht auch *sinnvoll*, das zu sperren, denn sonst sind die Ergebnisse widersprüchlich ('Aber ich habe doch die Änderungen gespeichert? Wieso sieht man das in der Statistik nicht? In meiner sieht man das aber, und die wurde zur gleichen Zeit erstellt. Admin: Du bist gefeuert!')

[himitsu]

Das kommt auch auf die Daten drauf an.

z.B. egal ob du nun selber das aufteilst, oder ob das System es macht.
Dank deines ORDER BY PrimaryKeyPreferablyWithAClusteredIndex im Beispielcode muß die DB sowieso erstmal die komplette Result-Tabelle zusammenstellen, um sie überhaupt erstmal sortieren zu können und danach wird und kann erst der Ausschnitt extrahiert werden.
Wenn du das nun immer wieder neu abfragst, dann macht das die DB praktisch jedes mal von Neuem.
Und selbst ohne Sortierung werden viele DBMS das Result vermutlich dennoch umkopieren, denn sonst müsste sie die Tabelle vermutlich für andere Schreibzugriffe sperren, bis man endlich alles runtergeladen hat. Oder diese Zugriffe landen so lange, wie bei einer Transaktion, im Cache und werden erst in die Tabelle geschrieben, nachdem du mit Runterladen der aktuellen Anfrage fertig bis.

Wenn man nun wirklich nur die Daten von oben nach unten durchgehen will, dann ist es doch besser, wenn die DB das nur einmal machen muß und man dann das Result sich vom System stückchenweise nachladen lässt?

[Dejan Vu]

Zitat von himitsu:

Dank deines ORDER BY PrimaryKeyPreferablyWithAClusteredIndex im Beispielcode muß die DB sowieso erstmal die komplette Result-Tabelle zusammenstellen, um sie sortieren überhaupt zu können

Nein! Nicht bei einem Clustered Index (deswegen heißt die Spalte ja so). Das ist der Trick. Bei einem Clustered Index liegen die Daten bereits sortiert im B-Baum.

Das bedeutet, das Du derartig angelegte Tabellen wirklich ohne jegliche Verzögerung durchscrollen kannst. Bei anderen RDMBS geht das anders. Bei SQL-Server aber eben so.

[himitsu]

Gut, Sortieren ist auch möglich, wenn man immer nur Ausschnitte kennt, aber das ist dann auch ein klitzekleines bissl aufwändiger.
[edit] Hmmm, beim Einfügen jedes Datensatzes kann man ist es einfacher, da dort ja nur "alles" mit dem jeweiligen Satz verglichen werden muß.

Na dann
Dann ist der Aufwand wohl in die Indexerstellung verschoben und braucht beim Auslesen nicht mehr gemacht zu werden.

[Dejan Vu]

Vom Sortieren muss man sich verabschieden, wenn man mit riesigen Datenmengen zu tun hat. Das ist aber auch irrelevant, denn -zum 1000000sten mal- anschauen tut sich das keine Sau. Klar will man immer ein Grid haben, in dem alle Daten sichtbar sind und man *könnte* wenn man wollte durch die Zeilen durchscrollen und man kann sortieren und gruppieren und superallesmachen. Aber...

dafür gibt es OLAP.