FireDAC + Firebird dynamisch optimieren

[stahli]

Ich habe soeben in meiner unendlichen Weisheit festgestellt, dass es sinnvoll sein kann, vernünftige Indizes zu definieren.

Bei 30T Datensätzen dauert es dennoch einen Moment, "select Count" abzuhandeln.

Ich muss dann halt wohl das Ergebnis zwischenpuffern und nur in bestimmten Fällen neu ermitteln. Wenn ich die Rückgabe per fester Vorgabe regle, dann läuft das ausreichend schnell.

Ich will diese "Optimierungen" letztlich aber meinem Framework und insbesondere meinem Gitter überlassen, so dass sich der Programmierer dann nicht mehr darum kümmern muss.
Gefühlt bindet man einfach die 1Mio Objekte bzw. Datensätze an das Gitter und das Framework beschafft dann die aktuell benötigten (weil gerade sichtbaren) Datensätze. Das funktioniert dann für diverse Listen und Datenmengen gleichermaßen.

Geringe Leistungseinbußen will ich dann zu Gunsten der effektiven Handhabung in Kauf nehmen.
Anbei mal die Count-Funktionen der beiden aktuellen ORM-Varianten (IBX + FireDAC) und die AQTime-Logs. Das muss natürlich jetzt noch gesäubert werden.

Delphi-Quellcode:

function TssOrmAd.ListItemsCount(O: TObject): Integer;
var
  TableName: string;
begin
  //  Exit(33901); // Simulation

  if not(O is TssObject) then
    Exit(0);
  if (O as TssObject).SaveMode then
    Exit(0);

  TableName := 'ItemsList'; 

  AdQuery.SQL.Clear;
  AdQuery.SQL.Add('select Count(*) from ' + TableName);
  AdQuery.SQL.Add('where Owner = :Owner');
  AdQuery.ParamByName('Owner').AsString := (O as TssObject).Id;
  AdQuery.Open;
  Result := AdQuery.FieldByName('Count').AsInteger;
  AdQuery.Close;
end;

...

function TssOrmIbx.ListItemsCount(O: TObject): Integer;
var
  TableName: string;
begin
  //  Exit(33901); // Simulation

  if not(O is TssObject) then
    Exit(0);
  if (O as TssObject).SaveMode then
    Exit(0);
  if IBSQL.Open then
    Exit(0);

  TableName := 'ItemsList';

  IBSQL.SQL.Clear;
  IBSQL.SQL.Add('select Count(*) from ' + TableName);
  IBSQL.SQL.Add('where Owner = :Owner');
  IBSQL.ParamByName('Owner').AsString := (O as TssObject).Id;
  IBSQL.ExecQuery;
  Result := IBSQL.FieldByName('Count').AsInteger;
  IBSQL.Close;
end;

[QuickAndDirty]

Also wenn ich das richtig verstanden habe machst du selbst datensensitive Gitter.
Ich würde mich von einer Count-Funktion verabschieden.
Die Gitter sollten sich so verhalten wie alle anderen datensensitiven Gitter die auf Queries arbeiten auch:
Der Laufbalken hat nur 3 Zustände oben, unten, in der mitte.

Benutzt man in Firemonkey auch diese Struktur?
TFMGRID <-> TGridDatalink <-> TDatasource <-> TQueryDataLink <-> TADQuery
oder macht es das anders?

Wenn du einfach mal ganze Tabellen "öffnen" können willst. Würde ich auf dem TADtable arbeiten, das macht das ganze caching usw. schon so intelligent wie möglich. (Livewindow,Recordcount &c.)

[stahli]

Ich habe ein eigenes Gitter und eine eigene Listbox, die an diverse Datenmengen gebunden werden können:

- an eine dumme TObjectList
- an eine dumme TIBQuery oder TAdQuery (optional an andere DataSets)
- an eine TssList, die dynamisch von meinem Framework bereitgestellt und gefüllt wird (z.B. TAbfallMain.GrundstueckList)

Die TssList kann ihre Daten wiederum
- in generischen Listen oder
- über einen ORM (aktuell IBX-FireBird, FireDAC-FireBird) verwalten.

TDataLink und ähnliche Controls benutze ich nicht.

Die Anzahl der Datensätze will ich immer wissen da das Grid schon scrollen soll, wenn man in die Nähe des Gitter-Randes kommt. So soll man beim scrollen nach oben und unten schon immer einige der nächsten Datensätze sehen. Standardmäßig ist ein Scroll-Rand von 20% der Gitterhöhe eingestellt. Dazu muss das Gitter aber wissen, wie viele Datensätze noch zur Verfügung stehen.

Die TssList kapselt sämtliche Verhaltensweisen intern auf die unterschiedlichen Datenspeicherarten weg. Insofern soll die TssList immer Auskunft geben können, wie viele Datensätze bzw. Objekte sie gerade representiert.

Bei der Speicherung der Daten in generischen Listen ist die Abfrage ja jederzeit ohne zeitliche Verzögerung möglich.
Bei Einsatz eines ORM frage ich die Anzahl über "Select Count(*)" ab und merke mir das Resultat bis Änderungen der Datenmenge vorgenommen werden.

Das funktioniert jetzt sehr gut und m.E. auch schnell genug.
-> http://www.delphipraxis.net/1216265-post20.html