paged query im Eigenbau?

[bernhard_LA]

wenn ich mir Daten vom Server in kleinen Portionen holen will könnte ich entweder Paged Queries

Delphi-Quellcode:

SELECT * FROM ( 
  SELECT *, ROW_NUMBER() OVER (ORDER BY name) as row FROM sys.databases 
 ) a WHERE a.row > 5 and a.row <= 10

oder in unserem Falls, da die meisten Tabellen auch ein "ziemlich fortlaufendes " Feld "RecordID" besitzen auf

Delphi-Quellcode:

select * from Mytable where recordID < MaxId and recordID>MinId

zurückgreifen.

Ist zwischen einer "paged-Query" und dem Eigenbau ein Unterschied bzgl. der Performance zu erwarten ?

[Namenloser]

Sorry für den möglicherweise dummen Beitrag, aber kann man das, was du da machst, nicht möglicherweise mit dem

Delphi-Quellcode:

LIMIT

-Befehl einfacher lösen? Der ist doch eigentlich genau für „paged queries“ gedacht.

[bernhard_LA]

LIMIT geht leider nicht für MSSQL

[Blup]

Halte ich beides nicht für sinnvoll, bei einer Query werden doch normalerweise nur so viele Datensätze geholt, wie mit Next auch angefordert?

[Uwe Raabe]

Bei MSSQL gibt es OFFSET und FETCH in der ORDER BY Klausel.

[Dejan Vu]

Ab SQL-Server 2012 geht das so:

SQL-Code:

SELECT * from Tabelle 
ORDER BY PrimaryKeyPreferablyWithAClusteredIndex
OFFSET @page*@windowSize ROWS 
FETCH NEXT @windowSize ROWS ONLY

[himitsu]

Arbeiten ordentliche DBMS mit passenden SQL-Komponenten nicht eh schon stückchenweise?
(auch entsprechend der Antwort von Blup)

z.B. pgDAC und Co. und (bestimmt) auch DBX/DataSnap laden die Datensätze nur stückchenweise nach, es sei denn man aktiviert eine Option, um die Daten alle sofort laden zu lassen.

Auch ordentliche DBGrids haben einen Modus, um möglichst nur die angezeigten Datensätze zu laden und nicht gleich alles in den eigenen Cache zu kopieren. (nur gibt es dann natürlich oftmals keine Sortierung oder Filterung mehr)

[Dejan Vu]

Zitat:

Zitat von himitsu (Beitrag 1262934)

Arbeiten ordentliche DBMS mit passenden SQL-Komponenten nicht eh schon stückchenweise?
(auch entsprechend der Antwort von Blup)

Nope. Und selbst wenn. Die Kleinigkeit kann man nun wirklich selbst bauen.

Zitat:

Auch ordentliche DBGrids haben einen Modus, um möglichst nur die angezeigten Datensätze zu laden und nicht gleich alles in den eigenen Cache zu kopieren. (nur gibt es dann natürlich oftmals keine Sortierung oder Filterung mehr)

Wozu das Grid, wenn die Daten doch eh nur geladen werden sollen?

Delphi-Quellcode:

Type
  TVirtualQuery<T> = class
  private 
    fTopIndex, fWindowSize : Integer;
    Procedure LoadWindow (page : Integer);
  public
    property Row[index : Integer] : T read GetRow; default;
  end;

...
Function TVirtualQuery<T>.GetRow (index : Integer) : T;
Begin
  Assert ((index>0) and (index < totalRows));

  if (index<fTopIndex) or (index>fTopIndex+fWindowSize-1) then 
    LoadWindow(index div PageSize);

  result := fData[index - fTopIndex];
End;

Procedure TVirtualQuery<T>.LoadWindow (page : Integer);
Begin
  fData := LoadPageFromSQLServer (page, windowSize); // mit dem SQL-Befehl von Uwe 
  fTopIndex := page*windowSize;
End;

Das ist die Logik. Den Rest kann man wuppdiwupp einfach selbst programmieren.

Wenn man ein wenig nachdenkt, braucht man kein 'totalrows', sondern läd einfach solange, bis der Server 'Error' meldet bzw. die Ergebnismenge leer ist. Ich weiss jetzt nicht genau, was der Server macht, wenn man eine Seite anfordert, die es gar nicht gibt...

[himitsu]

Der Vorteil, wenn es DBMS+Querykomponente das machen, daß dann die Daten konsistent bleiben, egal wie lange man drin rumscrollt, es bleibt immer in dem Zustand, wie zum Zeitpunkt der Abfrage.
Denn dort bleibt das Result-Set auf dem Server erhalten und das Query holt die Daten nur noch dort raus.

Bei den Aufteilen über einzelne Anfragen, könnte es ein Problem geben, wenn sich die Daten in der Tabelle zwischenzeitlich ändern.

[Dejan Vu]

Zitat:

Zitat von himitsu (Beitrag 1262948)

Der Vorteil, wenn es DBMS+Querykomponente das machen, daß dann die Daten konsistent bleiben, egal wie lange man drin rumscrollt, es bleibt immer in dem Zustand, wie zum Zeitpunkt der Abfrage.
Denn dort bleibt das Result-Set auf dem Server erhalten und das Query holt die Daten nur noch dort raus.

Und wie groß ist der Speicherverbrauch, wenn man einmal durchgescrollt hat und die Daten schön gecached sind und alle so, wie am Anfang?

Die Problematik hier liegt nicht am anschauen hübscher Terrabytes, sondern am skalierbaren durchlaufen einer sehr großen Datenmenge in akzeptabler Zeit. Da das lesen einzelner Datensätze einfach zu lange dauert, will der TE das happenweise machen. Dafür eignet sich nun mal das paging, denn das sind ja happen.

Mein Minipseudocode soll nur zeigen, wie man das hinter einer Art Liste verbergen kann. Man kann auch einfach einen Enumerator implementieren, dann kann man das komplett in einer for-in Schleife durchlaufen. Das wäre sogar noch richtigerer als mein kleines Dingsda, was ja eigentlich nur zeigen soll, wie simpel der ganze Kladderadatsch ist.