Schnellste Insert Möglichkeit für eine DB?

[moelski]

Moin !

Ah ok. So habe das mal angepasst mit erstaunlichem Ergebnis :-)
Count : 1000
1 Time : 12093 ms
2 Time : 9156 ms
3 Time : 6015 ms

Also nochmals deutlich schneller bei 1000 Datensätzen.

Das war jetzt alles auf Basis des Firebird Servers (2.5).
werde jetzt mal embedded testen und schaun ob das noch schneller geht?!

[moelski]

Moin !

So wenn ich das ganze embedded laufen lasse ändert sich nicht viel.

Count : 1000
1 Time : 6968 ms
2 Time : 6781 ms
3 Time : 4656 ms

Es ist zwar etwas schneller als auf dem Server, aber nicht wirklich gravierend.


Jetzt könnte man noch testen ob es etwas bringt wenn man mehrere INSERT in einen SQL Text packt.
Das würde aber auf der anderen Seite auch bedeuten das ich in der Anwendung die Daten puffern muss.

Mal sehen ob ich das noch teste ...

Wenn jemand noch einen anderen Vorschlag hat ... Nur her damit. :)

[shmia]

Die SQL-Befehle sollte man nicht über eine Query-Komponente absenden, sondern falls möglich direkt über das Connection-Objekt oder Database-Objekt.
Beim Zusammenbauen der SQL-Befehle sollte man darauf achten, dass man nicht Folgendes tut:

Delphi-Quellcode:

SQL := SQL + ....;

Hierbei würde jedes Mal der String verlängert, was zur Folge hat, dass ein neuer Speicherblock notwendig wird und dann der alte Block auf den neuen kopiert wird.

[moelski]

Ok ich werde das mal testen.

Wusste nicht dass das mit UniDac so geht.
Danke für den Hinweis.

[hoika]

Hallo,

was ich hier vermisse,
sind die Transaktionen.

sollte UniDAC wie die BDE arbeiten,
würde bei jedem ExecSQL ein StartTransaction / Commit gemacht.

Das sollte aber ausserhalb der Schleife passieren.

Delphi-Quellcode:

StartTransaction;
try
  Prepare;
  for
    ExecSQL;
finally
  Commit;
end;

Heiko

[moelski]

Hallo Heiko,

evtl. ist das Beispiel dafür ungeeignet, aber die Daten kommen bei mir ja im Sekundentakt später. Die For Schleife ist derzeit ja nur zum simulieren großer Datenmengen.

Muss ich dann zwangsläufig auch mit Transaktions arbeiten?

[s.h.a.r.k]

Zitat:

Zitat von shmia

Die SQL-Befehle sollte man nicht über eine Query-Komponente absenden, sondern falls möglich direkt über das Connection-Objekt oder Database-Objekt.

Warum *genau* sollte man das nicht tun?

Zitat:

Zitat von shmia

Beim Zusammenbauen der SQL-Befehle sollte man darauf achten, dass man nicht Folgendes tut:

Delphi-Quellcode:

SQL := SQL + ....;

Sowas darf ich dann aber machen, ohne dass es Probleme mit dem Speicher gibt, oder?

Delphi-Quellcode:

sql := 'SELECT * FROM ' + table + ' WHERE ID = ' + id + ' ORDER BY ' + order;

[Jürgen Thomas]

Zitat:

Zitat von s.h.a.r.k

Sowas darf ich dann aber machen, ohne dass es Probleme mit dem Speicher gibt, oder?

Delphi-Quellcode:

sql := 'SELECT * FROM ' + table + ' WHERE ID = ' + id + ' ORDER BY ' + order;

Sowas sollst du grundsätzlich nicht machen! Das hat nichts mit dem Speicher(n) zu tun, sondern ist eine Frage der Sicherheit und Geschwindigkeit (und wird in 1000 Beiträgen dringend empfohlen):

* Parameter vermeiden Probleme bei der Formatierung von Zahlen, Datumsangaben oder Hochkommata als Teil von Strings.
* Parameter verhindern Sql-Injection.
* Ein parametrisierter Befehl, der der DB schon bekannt ist, muss nicht neu analysiert werden und wird deshalb schneller ausgeführt. Ein Befehl, der z.B. durch die "eingebaute ID" jedesmal anders aussieht, muss jedesmal neu analysiert werden.

Ich hoffe, das ist so klar und eindeutig, dass es nicht mehr in Zweifel gezogen wird. Jürgen

[psychomama]

Darf ich dann bitte einmal fragen, wie man sonst eine dynamische SQL-Anweisung schreiben soll?!

[p80286]

Zitat:

Zitat von Jürgen Thomas

* Parameter vermeiden Probleme bei der Formatierung von Zahlen, Datumsangaben oder Hochkommata als Teil von Strings.
* Parameter verhindern Sql-Injection.
* Ein parametrisierter Befehl, der der DB schon bekannt ist, muss nicht neu analysiert werden und wird deshalb schneller ausgeführt. Ein Befehl, der z.B. durch die "eingebaute ID" jedesmal anders aussieht, muss jedesmal neu analysiert werden.

Ich hoffe, das ist so klar und eindeutig, dass es nicht mehr in Zweifel gezogen wird. Jürgen

Ach wenn ich Dir Recht geben muß, sind das keine allgemeingültigen Aussagen!
Wenn z.b. der Benutzer keine Chance hat an den SQL-Text zu kommen (Injection), dann kann

SQL-Code:

sql:=sql+....

durchaus sinnvoll sein.
In den allermeisten Fällen ist Deine Aussage korrekt, aber es gibt eben auch Ausnahmen, darum sollte man nicht ganz so dogmatisch sein.

Gruß
K-H