SQL Update-Befehl viel zu langsam

[vagtler]

Ich tippe auch auf einen Fehler auf Grund mangelnder SoC (http://en.wikipedia.org/wiki/Separation_of_concerns). Warum für Update kein ausschließlich dafür zuständiges Objekt (durchaus gerne mit begrenzter Lebenszeit) verwenden?

[Perlsau]

Manchmal hilft es, einfach nur ein paar Hinweise aus anderen Köpfen zu lesen, um die eigenen Denkprozesse aus der Sackgasse zu führen. Dank eurer Antworten bin ich auf eine ganz einfache Lösung gestoßen: Stored Procedures in der DB anlegen und die bei Bedarf aufrufen:

Delphi-Quellcode:

Procedure TDatBankEdit.Vst_Mark(Modus: Byte);
begin
  DatMod.Dsrc_Berufe.Enabled := False;
  CASE Modus OF
  0 : DatMod.StoredProcMain.StoredProcName := 'BERUFE_MARKNONE';
  1 : DatMod.StoredProcMain.StoredProcName := 'BERUFE_MARKALL';
  2 : DatMod.StoredProcMain.StoredProcName := 'BERUFE_MARKTOGGLE';
  END;
  DatMod.Trans_Main.Active   := True;
  DatMod.Trans_Update.Active := TRue;
  DatMod.StoredProcMain.ExecProc;
  DatMod.Qset_Berufe.Refresh;
end;

Dabei werden meine knapp 24.000 Einträge in 0,8 bis 0,9 Sekunden aktualisiert. Somit sei euch allen, die ihr meine grauen Zellen erfolgreich angeregt habt, herzlich gedankt

[IBExpert]

Ich finde generell ein Update auf 24000 Datensätzen in 5 Sekunden relativ lahm, kann aber an deiner Tabellenstruktur liegen oder
an der verwendeten Festplatte (bei SSDs sollte das schneller sein) oder auch an denr Firebird Version bzw Parametern wie cache
Buffers usw. Falls Trigger auf der Tabelle sind, dann würden die ja ggf auch ausgeführt werden. Ich habe gerade mal einen Test
auf einer lokalen DB gemacht und bin dabei (mit SSD) auf 25000 Updates in 0,75 Sekunden gekommen.

Mir kam dabei aber noch folgende Idee: Flüchtige Daten wie die Markierungen sind ausgeprochen unsinnig in der Tabelle selbst
gespeichert, weil du damit schon mal keine netzwerkfähigkeit hast. Wie wäre eine extra Tabelle, die nur die Primärschlüssel
deiner Tabelle speichert, die ausgewählt sind (optional mit User, der markiert, und schon wäre das netzwerkfähig).
Für das Füllen des Treeview verbindest du deine Daten per left outer join mit den Markierungen. Wenn 100 Datensätze
markiert sind, hast du bei meinem Verfahren 100 Datensätzen mit pk in einer extra Tabelle, die vieleicht gerade
mal eine Datenpage belegt. Bei deinem Verfahren hast du 23900 mal den Feldwert 0 und 100 mal den Feldwert 1, verteilt
auf sämtliche Datenpages. Bei Update (insbesondere alle Markierungen löschen) werden dann nämlich bei deinem Verfahren
sämtliche Datenpages verändert, bei meinem Verfahren gibt es nur ein paar Deletes in wenigen Datenpages.


Wenn es aber generell um die Erkenntnis geht, was da den Geschwindigkeitsunterschied auf Seite von Firebird ausmacht, dann:

wenn du die ibexpert vollversion hast, dann steht dir in Services-Database Monitor eine Liste der ausgeführten SQLs zur Verfügung
http://ibexpert.net/ibe/index.php?n=...0#DBMonitoring
Mit der Personal Edition musst du dir das händisch aus der MON$STATEMENT zusammensuchen

Da wird es sicherlich schon einige Unterschiede geben, Delphi Komponenten machen gerne mal viel unsinnigen Overhead.
Noch detaillierter liefert dir die TraceAPI dazu Ergebnisse, weil darin alle Befehle protokolliert werden, auch ausgeführte
Trigger etc.
http://ibexpert.net/ibe/index.php?n=...#TraceAndAudit
Bei der Personal Edition fehlt das, aber die Firebird Kommandozeilentools könnte man auch benutzen.

p.s.: Wer umsteigen will von der Personal Edition: Einfach mal den Code DPSPECIAL im IBExpert Shop ausprobieren

Ich geh erfahrungsgemäß davon aus, das die Geschwindigekeitsunterschiede durch Delphi Kompnenten versursacht werden, das kannst
du normalerweise mit der traceapi oder im sql monitor sehr schnell finden