TIBSQL vs isql-fb Shell

[IBExpert]

Zitat von jobo:

IdR. ist eine Query Komponente nicht mal in der Lage, ein Script(mehr als einen Befehl hintereinander) auszuführen. Dafür gibt es separate Scriptkomponenten.

Einspruch, zumindest für Firebird >=2.x kannst du mehrere insert/update/delete Befehle semikolon getrennt zB in einer TSTringlist sammeln, dann schreibst du EXECUTE BLOCK AS BEGIN davor und ein END dahinter und schon kannst du mit nahezu jeder SQL Query Komponente mehrere Befehle auf ein mal senden (Bei manchen Komponenten musste du deren interne Prüflogik abschalten, wenn die zu blöd sind, execute blocks korrekt zu erkennen).

Das beschleunigt die Ausführung noch mal erheblich, hat aber ein paar Grenzen (maximal 255 Relationen pro block, also 255 inserts oder 127 updates oder 85 "update or insert", gerne aber auch gemischt, als Richtwert einfach maximal 80 Befehle pro Block, gesamter source kleiner als 32k,...)

Bei solchen Anforderungen bringt das erhebliche Geschwindigkeitsvorteile aus einer Delphi/Lazarus Anwendung, aber wie die anderen schon sagten, man sollte bei der Geschwindigkeitsmessung die Zeit nicht verplempern mit visualisierungen, es bringt dir nix an Erkenntnissen zur Optimierung deiner SQL Operationen, wenn die SQLs am ende für 1% der Laufzeit verantwortlich sind und 99% irgendwelche TMemos auf dem Screen vertrödeln

Außerdem nicht vergessen, wenn es um High Speed geht, hilft auch die Benutzung des lokalen Protokolls xnet oder noch schneller importe per external tables ...

Aber mal ganz ehrlich, dein Source ist aus meiner Sicht nicht annähernd hilfreich, um den SQL Speed neutral zu bewerten, dafür solltest du klarer trennen zwischen Zeitaufwand für das senden der SQL Befehle und irgendwas anzuzeigen. Nicht vergessen, 10000 mal 1ms sind 10 Sekunden

[jobo]

Einspruch zum Einspruch.

Was Du beschreibst, ist eine Fähigkeit des Servers, nämlich einen Anonymous Block ausführen zu können, also im Prinzip eine Stored Procedure ohne Signatur / Header. Diese Fähigkeit hat nichts mit der Query Komponenten und ihre Bestimmung zu tun. Sie ist ein Servermerkmal, wie es ähnlich auch bei anderen Server vorzufinden ist, keine Fähigkeit der Query Komponente.

Das hat nichts mit einem Script zu tun, wie man dann den von Dir genannten Einschränkungen auch entnehmen kann und wie sie auch dem TE mit 10000 Inserts nicht helfen würden für seinen Test bzw. Vergleich.

Ich bleibe dabei, um das Verhalten einer Konsole nachzustellen oder vergleichbar zu machen, bräuchte man eine entsprechende Script Komponente.

ot (nur weil es mir wichtig scheint)
Was alles nichts daran ändert, dass ich ein großer Freund von anonymous blocks bin. Sie verleihen eine riesen Power, nicht nur hinsichtlich Roh-Performance auch beim impliziten Transaktions Handling und damit Ressourcen schonenden DML. Hab ich an anderen Stellen schon vielfach betont. Dieses Feature macht auch Firebird zu einem sehr sympathischen System.

Dennoch für den TE zum Verständnis vielleicht ein hilfreicher Vergleich. Die Funktionsweise eines anonymous block, bei der alle Statements ohne Interaktion mit dem Client stumpf auf dem Server ausgeführt werden, verdeutlicht ganz gut die Unterschiede und liefert eine Erklärung für die geringere Geschwindigkeit, bei schrittweiser Ausführung auf dem Client. Jegliches Feedback zum Client entfällt (außer am Ende, z.B. nach dem 255. Insert), keine Allocs, keine Latenzen (die besonders jenseits von MBit/ GBit LAN übel aufstoßen können.
/ot