Querystring präparieren

[EgonHugeist]

Zitat von 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?

Ja so ist es.

Zitat von Codehunter:

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?

Zitat von Codehunter:

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

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.

Zitat von Codehunter:

Bei INSERT und UPDATE mit prepared Statements war es so:

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

Auch hier sehe ich Spielraum für noch bessere Benchmarks.

Zitat von Codehunter:

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?!

[Codehunter]

Zitat von EgonHugeist:

Das is schade. War kein OpenSource, oder?

Jetzt frag mich mal was leichteres. Der Code ist mittlerweile öffentlich zugänglich aber IMHO keineswegs als FOSS zu betrachten. Der ursprüngliche Anbieter (Devrace) hat sich irgendwann einfach in Luft aufgelöst, ohne Ankündigung oder Erklärung. Wo kein Kläger da kein Richter, aber formal dürften wohl nur ehemalige Lizenznehmer wie wir berechtigt sein, diese Quellen zu verwenden.

Zitat von EgonHugeist:

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.

Das ist gut möglich.

Zitat von EgonHugeist:

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

Das wäre wohl ein Fall für einen neuen Benchmark

Zitat von EgonHugeist:

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.

IMHO ging Ansgar Becker bei HeidiSQL vor Jahren auch schon diesen Weg bzgl. dem Mysql-Konnektor. Dass das Weglassen diverser Abstraktion der Performance guttut, liegt ja in der Natur der Sache. Die spannende Frage dürfte sein, wie sich der Migrationsaufwand für Altprojekte gestaltet. Wenn man dann mit viel Aufwand doch wieder eine eigene Abstraktion bauen muss, steht man am Ende wieder da wo man vorher war. Bei neuen Projekten könnte das sicher eine Alternative sein.

[mikhal]

Habt ihr auch die IBDAC von Devart statt der UniDAC getestet? Die sind auch speziell für Interbase / Firebird geschrieben und sollten neben einer besseren Performance noch einige Admin-Funktionalitäten mitbringen.

Gruß Mikhal

[Codehunter]

Zitat von mikhal:

Habt ihr auch die IBDAC von Devart statt der UniDAC getestet? Die sind auch speziell für Interbase / Firebird geschrieben und sollten neben einer besseren Performance noch einige Admin-Funktionalitäten mitbringen.

Nein. UniDAC stand überhaupt nur deshalb für den Benchmark zur Verfügung, weil ich privat eine Lizenz dafür habe. Soweit ich weiß, deckt eine UniDAC-Lizenz nicht die spezialisierteren DACs von Devart ab. Die Trials sind der Website zufolge begrenzt was die Tabellenbreite angeht, daher nutzen die nix für den Benchmark. Und nur dafür 500 bzw. 700 Euro ausgeben und die Pro-Lizenz kaufen, ähm nö, das geht bei uns in der GL nicht durch.

[EgonHugeist]

Zitat von CodeHunter:

Das wäre wohl ein Fall für einen neuen Benchmark

Dem würde ich mit Freuden entgegensehen. Aber es sollte veröffentlicht werden, damit jeder sich seine eigen Meinung bilden kann. Ebenfalls wäre wüschenswert, dass das Benchmark nicht von TDataSets abhängt. Soll heißen das mORMot TSQLDBStatement/ISQLDBRows oder Zeos IZPreparedStatemnt/IZResultSet sollte in gleicher weise testbar sein, wie FireDac, IBX, UniDac etc.

Doch ich habe keine Zeit dafür, Arbeit + Zeos sind genug.

Vielleicht ist da ein Sportsmann, den es interessiert so etwas umzusetzen?

Zitat von CodeHunter:

IMHO ging Ansgar Becker bei HeidiSQL vor Jahren auch schon diesen Weg bzgl. dem Mysql-Konnektor.

Ansgar hatte mal Zeos genutzt, da aber Zeos im Winterschlaf lag, was den Unicode-Support betraf, bis ich das mal mehr oder weniger gut gelöst hatte (bin rückblickend auf 7.1 nicht mehr stolz), hatte Ansgar Zeos verlassen(noch lange bevor ich ein Zeos-Dev-Member wurde), nutzt dennoch die DataSet's afaik.

Zitat von Mikhal:

Habt ihr auch die IBDAC von Devart statt der UniDAC getestet? Die sind auch speziell für Interbase / Firebird geschrieben und sollten neben einer besseren Performance noch einige Admin-Funktionalitäten mitbringen.

Wenn die Frage an die mORMot Tests gerichtet war, welche ich verlinkt hatte, wäre die Antwort: Nein. Ich kann mir auch nicht vorstellen, daß Arnaud weiter Anstrengungen unternehemen wird weitere DB.pas DataSet-Descentants zu implementieren, da er es war, welcher mich auf das bottleneck TDataSet brachte. Das mORMot Framework ist bekannt für Hochgeschwindigkeit, sticht dabei DataSnap die Augen aus, somit würden weiter DAC-Treiber basierend auf db.pas nur noch via constribution bei ihm erscheinen. Aber warum das tun, wenns danach nicht besser wird...

[Codehunter]

Zitat von EgonHugeist:

Doch ich habe keine Zeit dafür, Arbeit + Zeos sind genug. Vielleicht ist da ein Sportsmann, den es interessiert so etwas umzusetzen?

Das ist bei mir nicht anders. Selbst wenns eine Foundation gäbe für Delphi, Lazarus & Co., mehr Zeit kann einem keiner kaufen

Zitat von EgonHugeist:

Ansgar hatte mal Zeos genutzt, da aber Zeos im Winterschlaf lag, was den Unicode-Support betraf, bis ich das mal mehr oder weniger gut gelöst hatte (bin rückblickend auf 7.1 nicht mehr stolz), hatte Ansgar Zeos verlassen(noch lange bevor ich ein Zeos-Dev-Member wurde), nutzt dennoch die DataSet's afaik.

Das kann ich soweit bestätigen, er hat mir das selbe erzählt. Ich wurde vor langem Member bei HeidiSQL und musste meine Mitarbeit dort wg. chronischem Zeitmangel nach meinem Arbeitgeberwechsel auf Eis legen. Ich hatte dort insbesondere an einer neuen Benutzerrechte-Verwaltung für MySQL gearbeitet.

Zitat von EgonHugeist:

Wenn die Frage an die mORMot Tests gerichtet war, welche ich verlinkt hatte, wäre die Antwort: Nein. Ich kann mir auch nicht vorstellen, daß Arnaud weiter Anstrengungen unternehemen wird weitere DB.pas DataSet-Descentants zu implementieren, da er es war, welcher mich auf das bottleneck TDataSet brachte. Das mORMot Framework ist bekannt für Hochgeschwindigkeit, sticht dabei DataSnap die Augen aus, somit würden weiter DAC-Treiber basierend auf db.pas nur noch via constribution bei ihm erscheinen. Aber warum das tun, wenns danach nicht besser wird...

mORMot, das ist so ähnlich wie Tesla: Hat man mal gehört, soll sehr innovativ sein, aber so richtig traut man sich nicht ran Es ist manchmal echt zum Heulen. Es gibt viele Dinge die einem die Arbeit erleichtern könnten, aber es fehlt wg. dem Alltagsgeschäft die Zeit sich einzuarbeiten.

[Codehunter]

Also die ZEOS 8.0 konnte ich nicht finden, aber die aktuelle 7.2.8 habe ich mir besorgt. Da ist ein kleines Fehlerchen in der ZDbcSqLiteResultSet.pas:

Delphi-Quellcode:

{$IFNDEF ZEOS_DISABLE_SQLITE} //if set we have an empty unit
uses
  {$IFDEF WITH_TOBJECTLIST_REQUIRES_SYSTEM_TYPES}
    System.Types, System.Contnrs // <--- HIER FEHLT EIN KOMMA
  {$ELSE}
    {$IFNDEF NO_UNIT_CONTNRS}Contnrs,{$ENDIF}
  {$ENDIF}
  Classes, {$IFDEF MSEgui}mclasses,{$ENDIF} SysUtils, ZClasses,
  ZSysUtils, ZDbcIntfs, ZDbcResultSet, ZDbcResultSetMetadata, ZPlainSqLiteDriver,
  ZCompatibility, ZDbcCache, ZDbcCachedResultSet, ZDbcGenericResolver,
  ZSelectSchema;

[EgonHugeist]

Zitat von Codehunter:

Also die ZEOS 8.0 konnte ich nicht finden, aber die aktuelle 7.2.8 habe ich mir besorgt. Da ist ein kleines Fehlerchen in der ZDbcSqLiteResultSet.pas:

Delphi-Quellcode:

{$IFNDEF ZEOS_DISABLE_SQLITE} //if set we have an empty unit
uses
  {$IFDEF WITH_TOBJECTLIST_REQUIRES_SYSTEM_TYPES}
    System.Types, System.Contnrs // <--- HIER FEHLT EIN KOMMA
  {$ELSE}
    {$IFNDEF NO_UNIT_CONTNRS}Contnrs,{$ENDIF}
  {$ENDIF}
  Classes, {$IFDEF MSEgui}mclasses,{$ENDIF} SysUtils, ZClasses,
  ZSysUtils, ZDbcIntfs, ZDbcResultSet, ZDbcResultSetMetadata, ZPlainSqLiteDriver,
  ZCompatibility, ZDbcCache, ZDbcCachedResultSet, ZDbcGenericResolver,
  ZSelectSchema;

Habe ich im SVN: https://sourceforge.net/p/zeoslib/co...s/7.2-patches/ bereits gefixt. Ich teste die alten Version nur beim Merge und diese Compiler (mit dem define) habe ich wohl übersehen. Ein zwischen release ist in Arbeit.

Wegen der 8er Version:
gehe auf https://sourceforge.net/p/zeoslib/co...AD/tree/trunk/ und clicke "Download Snapshot" oben rechts. Es giebt noch kein bundle, da die Dokumentationen noch nicht fertig sind.
7.2.8 enthält nur Bug-Fixes (auch deine sind dabei -> MySQL UTF8-Bin war als TBytes interpretiert worden), soll heißen es wird auch nicht schneller..