Also wenn ich das richtig verstehe, ist die magische Zeile diese:
Query.Params.BatchDMLCount := 10;
Damit definierst du, wie viele (gleiche) Zeilen es gibt und mit dem
AsIntegers[DMLidx]
spricht man dann die jeweilige Zeile an?
Ja so ist es.
Hintergrundinfo: Wir hängen immer noch bei
FB 2.5 fest, weil wir in den Vendor-Lock-In getappt sind. Als DAC haben wir uns vor vielen Jahren für FIBplus bzw. FIBtools entschieden. Zu der Zeit gabs noch gar kein FireDAC usw. Dummerweise hat der Hersteller von FIBplus irgendwann jegliche Tätigkeit eingestellt. Bis D 10.2.3 lassen sie sich noch kompilieren, danach ist Feierabend. Wir haben zwar die Quellen, aber die sind doch sehr "speziell" und schwer zu warten.
Das is schade. War kein OpenSource, oder?
Wir haben dann mal eine Art Benchmark gebaut um zu vergleichen, welches DAC wie schnell ist. Im Rennen waren FIBplus, FireDAC, UniDAC und ZEOS. Bei SELECT-Queries mit diversen JOINS usw. sowie anschließender Iteration war das Ergebnis:
- FIBplus
- FireDAC
- ZEOS
- UniDAC
Soweit ich mich erinnere habt ihr das noch Zeos 7.2 gemacht... Ich denke da ist seit ich an der 8er Reihe arbeite noch Luft nach oben für Zeos.
Bei INSERT und UPDATE mit prepared Statements war es so:
- FIBplus
- ZEOS
- FireDAC
- UniDAC
Auch hier sehe ich Spielraum für noch bessere Benchmarks.
Wobei ich betone, die Quellen für den Benchmark sind aus der Erfahrung mit FIBplus entstanden und das Datenbankmodell womöglich auch daraufhin optimiert ist. Die FIBtools sind halt speziell für Interbase und Firebird macht worden und bis heute unschlagbar was die Performance bei Single-Queries angeht.
Spannend ist jedoch die Frage, wie schaut das Ganze bei Batch-Queries und Random
Access (wie es im Zusammenspiel mit Devexpress häufig vorkommt) aus. Und da scheinen die FIBtools brutal in die Knie zu gehen. Das scheint ein Designproblem zu sein, weil die FIBtools anscheinend zwischen zwei Queries viel Zeit mit Aufräumen verbringen.
Nun können wir nicht ewig bei
FB 2.5 bleiben. Vermutlich wird dieser Zweig spätestens mit dem Erscheinen von
FB 4.0 aus jeglichem Support fallen. Irgendwann kommt dann vllt. ein Windows-Update und beerdigt den 2.5er Zweig. Ein Projekt wie unseres migriert man aber auch nicht im Handstreich auf eine andere
DB. Schon gar nicht, wenn damit auch ein Wechsel des DAC verbunden ist.
FireDAC, UniDAC und ZEOS sind alle Multi-Backend-fähig. Das wird wohl darauf hinaus laufen, eins von diesen zu wählen. FireDAC ist das performanteste von diesen, jedoch zusammen mit UniDAC auch wieder mit der Gefahr eines Vendor-Lock-in behaftet. UniDAC zudem noch mit einem großen Abstand das langsamste. Für mich hätte ZEOS durchaus einen gewissen Charme, nur bin ich nicht der der am Ende entscheidet.
Cody ich kann zu den anderen Komponenten nicht viel sagen. FireDac kenne ich nur von der Emba-Hilfe. Wenn's aber um wirklich TOP-Performace geht: Schmeiß alle DataSet-Komponenten weg und nutze den ZDBC Layer.
https://synopse.info/forum/viewtopic.php?id=5560
Wie man deutlich sehen kann schüttelt Zeos die UniDac und FireDac deutlich ab. Ich wüßte kein FrameWork, welches eine 2. Art des Zugriffs bietet außer Zeos. In meinen Projekten nutze ich DataSet's nur noch für
GUI+
DB-Komponenten. Ansonseten hab ich die DataSets beerdigt. Dank all der DBGrid und Field-kompatibilität kann man klar sagen: Desto schneller der Server, desto höher der Geschwindigkeitsverlust durch die DataSets. Da alle von T(Custom)Dataset ableiten, haben auch alle das gleiche Problem. Wenn ich Massen-DML/CRUDS's am Laufen habe, soll's doch richtig schnell gehen und der Server sollte das Nadelöhr sein... Ich war noch vor ein paar Jahren TDataSet-Fan.. Wie sich Dinge ändern können, wenn man sich Alternativen öffnet?!