FMX-FireDac "!" Fehler oder Feature?

[Mikkey]

Zitat von Mavarik:

Gerade auf IOS & Android geht es um Performance... Müssen die Parameter nicht alle wieder als ein SQL String zusammengebastelt werden damit dieser an den Treiber übergeben werden kann?

Nö, das ist ja gerade der Sinn, dass die Werte nicht aus dem SQL-String herausgeholt werden müssen.

Zitat von Mavarik:

Außerdem sehe ich da keinen Vorteil...

Naja, dieses(!) Problem hättest Du nicht gehabt

[Daniel]

Stichwort "Performance": Solltest Du gleich eine größere Anzahl an Werten haben, dann könntest Du die "Batch-Funktionalität"-FireDAC nutzen. Grob gesagt übergibst Du der FireDAC-Komponente ein mehrdimensionales Array an Werten und lässt sie dann machen. Gegenüber einzelnen Requests konnte ich da Performance-Steigerungen um den Faktor 10 (!) erzielen.

Details dazu unter:
http://docwiki.embarcadero.com/RADSt..._DML_(FireDAC).

[Bernhard Geyer]

Zitat von Mavarik:

Gerade auf IOS & Android geht es um Performance... Müssen die Parameter nicht alle wieder als ein SQL String zusammengebastelt werden damit dieser an den Treiber übergeben werden kann?

Der Treiber muss gar nix zusammenbauen sondetn übergibt das parametrisierte Statement an die Db welche sich dann leichter tut das Statement abzuarbeiten. Nicht umsonst sind prepared Statement schneller als statements die ohne parameter arbeiten.

Zitat:

Außerdem sehe ich da keinen Vorteil...
Natives SQL "sollte" immer funktionieren...

Mavarik

Was ist natives Sql?

[Mavarik]

Zitat von Daniel:

Stichwort "Performance": Solltest Du gleich eine größere Anzahl an Werten haben, dann könntest Du die "Batch-Funktionalität"-FireDAC nutzen. Grob gesagt übergibst Du der FireDAC-Komponente ein mehrdimensionales Array an Werten und lässt sie dann machen. Gegenüber einzelnen Requests konnte ich da Performance-Steigerungen um den Faktor 10 (!) erzielen.

Details dazu unter:
http://docwiki.embarcadero.com/RADSt..._DML_(FireDAC).

Ja eben...

unter SQLite werden Parameter von FireDac nur emuliert.
und um aus einem String mit
SQL.Text := 'insert into Customers (ID, RegionID, Name, Note) values (:ID, :RegionID, :Name, :Note)';
wieder eine SQL Anweisung zu machen muss Firedac den String wieder zusammen bauen...
Weil die SQLite.dll nur SQL-Strings verarbeiten kann.

Übrigens ein

Delphi-Quellcode:

    SQLQuery.SQL.Text := 'BEGIN;';
    ...// inset 10000 Datensätze
    SQLQuery.SQL.Text := 'COMMIT;';

Hat zur Folge das erst alles in RAM kopiert wird und dann gebündelt an die DLL übergeben wird.

[mquadrat]

String-Operationen sind im Vergleich zu den ganzen grafischen Sachen und Animationen doch nicht wirklich teuer. Ich bezweifel, dass man da tatsächlich einen Geschwindigkeitsunterschied auf Android/iOS sieht. Wir verwenden in unserem Web-Framework auch RegExen und alle möglichen anderen String-Operationen (bei jedem Request) und erzielen trotzdem Geschwindigkeiten bei denen eine solche Pseudo-Optimierung schlicht nicht nötig ist.

Die meisten Projekte verwenden ja inzwischen ORMs und da wird IMHO auch immer mit Parametern gearbeitet. Noch dazu ist der ORM an sich ja noch mal eine Ebene der Indirektion, die Ressourcen benötigt.

Wir selber schreiben inzwischen nicht mal mehr die Queries, sondern nutzen einen Query-Builder mit Fluent-Interface, der ganz am Ende erst das parameterisierte Statement zusammenbaut.

[Daniel]

Frank, mach es so, wie Du Dich damit am besten fühlst.

Aber zwei Sachen kann man nicht stehen lassen, weil sie schlichtweg falsch sind:

Zitat von Mavarik:

unter SQLite werden Parameter von FireDac nur emuliert

Nein, weder einfache Parameter noch Array-Parameter werden emuliert. Einfache Parameter gehen immer und Array-Parameter gehen, wenn Du die Komponente entsprechend konfigurierst, indem Du die Eigenschaft "Params.BindMode" auf den Wert "pbByName" setzt. Seit iOS 6 (!) kommt SQLite in Version 3.7.13 daher und erfüllt damit die Voraussetzung für eine native Unterstützung von Array-Parametern.

Zitat von Mavarik:

Weil die SQLite.dll nur SQL-Strings verarbeiten kann

Ich bin durchaus froh, dass dem nicht so ist, denn sonst gäbe es ... sagen wir ... gewisse Probleme ... mit BLOB-Feldern.


Ich denke, es ist klar geworden, dass Du diesen Weg nicht gehen möchtest und das ist Dein gutes Recht.