Querystring präparieren

[Codehunter]

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?

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.

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:

1. FIBplus
2. FireDAC
3. ZEOS
4. UniDAC

Bei INSERT und UPDATE mit prepared Statements war es so:

1. FIBplus
2. ZEOS
3. FireDAC
4. UniDAC

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.