Schnellste Insert Möglichkeit für eine DB?

[Jürgen Thomas]

Zitat von psychomama:

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

Beispielsweise so, wie es oben in #5 und #7 gemacht wurde. Die Tabellen, Spalten und JOINs dürfen selbstverständlich dynamisch zusammengesetzt werden; auch die Parameter dürfen auf diese Weise dynamisch eingebaut werden, aber keinesfalls die Werte für die Parameter.

Zitat von p80286:

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

Es mag solche Ausnahmen geben. Aber die Regel ist so eindeutig; ich wundere mich sowieso, dass das in dieser Diskussion nicht viel deutlicher gesagt wurde, sondern nur implizit danach gehandelt wurde.

Jürgen

[s.h.a.r.k]

@Jürgen Thomas: Das mit den Paramtern kannte ich schon Meine Frage hatte eher etwas mit der Speicherwaltung zu tun, wenn ich einen String über "+" zusammenbaue. Man merkt vor allem schnell, dass es zu einem Problem werden kann, wenn man verschiedene Dateitypen in eine DB klopfen kann und das über einen einzigen SQL-String machen will. Man muss die Logik der Params halt selbst basteln -> unnötige Arbeit.

Zitat von s.h.a.r.k:

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?

Diese Frage wäre noch offen

[IBExpert]

wenn du es von der Applikationsseite wirklich schnell haben willst, dann achte auf die Transaktionssteuerung und auf das prepare außerhalb der schleife und tausche innerhalb der Schleife nur noch die parameter aus. Bei jedem execsql kommt dann sonst ein riesen overhead zu stande. Den Tip von hoika also auf jeden Fall ernst nehmen. Wenn du jedoch in der Schleife das SQL änderst, dann macht der client beim server sowieso ein unprepare und ein neues prepare mit jedem execsql. Damit würdest du wieder Geschwindigkeit verlieren.

Wenn die Daten zum Beispiel als Datei vorliegen, dann konvertier ich die lieber mit Delphi in ein Fixed format (pro zeile wird jedes feld mit Leerzeichen aufgefüllt).
von csv

SQL-Code:

ID;ZAHL;TXT;TXT2;ZAHL2
1;2;abc;xy;5
2;1;asd;yss;7
4;1;bbs;ddd;5

in fixed format, z.B.

SQL-Code:

1  2 abc xy  5
2  1 asd yss 7
4  1 bbs ddd 5

die datei dann zum Beispiel als c:\dat.txt speichern

dann in firebird

SQL-Code:

create table dat_ext external file 'C:\dat.txt'
(id char(3),
zahl char(2),
txt char(4),
txt2 char(3),
zahl2 char(1),
crlf char(2))     --zeilenumbruch in Textdatei belegt bei windoof 2 byte

als interne tabelle zum Beispiel

SQL-Code:

create table dat 
(id integer,
zahl integer,
txt char(4),
txt2 char(3),
zahl2 integer)

dann in firebird

insert into dat select id,zahl,txt,zahl2,txt2 from dat_ext
und dann ganz einfach

drop table dat_ext; damit bekommst du locker 20000 bis 100000 records pro sekunde in die Datenbank. Das geht in einer Transaktion mit wenigen execsqls, dabei ist dann der prepare auch egal.

Das entspricht dem Tip von chaosben und schlägt alle anderen verfahren um längen.

So ein Präprozessor, also ein simples Programm was aus deinen vorhandenen Daten eben so ein fixed format erzeugt ist in Delphi sogar mit TStringlist schnell zusammengeklöppelt und braucht sicherlich auch für 100000 records weniger als eine Sekunden, wenn das nicht ganz bescheuert programmiert ist.


Schöne Grüße

[shmia]

Zitat von s.h.a.r.k:

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?

Aus Performancegründen.
Ich beziehe mich hier mal auf ADO-Komponenten.
Wenn man einen INSERT direkt über Connnection.Execute('INSERT INTO ....') einreicht, dann ist man deutlich schneller als wenn man dies über eine ADOQuery oder ADOCommand tut.

Auch bei anderen Datenbank-Komponenten, die das Konzept einer Connection haben muss das so sein.
Letztendlich gibt eine Query ihren SQL-Befehl immer an die Connection- oder Database-Komponenten weiter.

[p80286]

Zitat von shmia:

Aus Performancegründen.
Ich beziehe mich hier mal auf ADO-Komponenten.
Wenn man einen INSERT direkt über Connnection.Execute('INSERT INTO ....') einreicht, dann ist man deutlich schneller als wenn man dies über eine ADOQuery oder ADOCommand tut.

Auch bei anderen Datenbank-Komponenten, die das Konzept einer Connection haben muss das so sein.
Letztendlich gibt eine Query ihren SQL-Befehl immer an die Connection- oder Database-Komponenten weiter.

wofür ist dann die TQuery noch gut?

Gruß
K-H

[Bernhard Geyer]

Zitat von p80286:

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:=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.

Dann viel Spaß beim Erklären wenn in einem Sicherheitsaudit der Auditor erstmal den SQL-Tracer anschmeißt und sieht das es Stellen gibt die nicht mit parametrisierte Abfragen laufen. Wie willst du Sicherstellen das die Methode die sowas macht nicht doch mal mit Werten auf User-Eingaben gefüttert wird? Z.B. 2ter Entwickler der die internas einer Methode nicht kennt bzw. sich nicht anschaut.

[shmia]

Zitat von p80286:

wofür ist dann die TQuery noch gut?

TQuery braucht man immer dann, wenn man eine Datenmenge zurückerwartet (das ist im Prinzip alles was mit SELECT ... anfängt).
TQuery bietet jede Menge Komfort (Parameter, Events,..) der halt etwas Zeit kostet.

[p80286]

Hallo Berhard

Zitat von Bernhard Geyer:

Dann viel Spaß beim Erklären wenn in einem Sicherheitsaudit der Auditor erstmal den SQL-Tracer anschmeißt und sieht das es Stellen gibt die nicht mit parametrisierte Abfragen laufen. Wie willst du Sicherstellen das die Methode die sowas macht nicht doch mal mit Werten auf User-Eingaben gefüttert wird? Z.B. 2ter Entwickler der die internas einer Methode nicht kennt bzw. sich nicht anschaut.

in Meiner Praxis gibt es z.B. folgende Situation:

Code:

select tabtyp from Tabelle1;

case tabtyp of
  Akte1 : sqltext:= 'select info from Tabelle2';
  Akte2 : sqltext:= 'select info from Tabelle3';
  Akte3 : sqltext:= 'select info1 from Tabelle4,Tabelle5 where Tabelle4.xid=Tabelle5.txid';
usw.

wie willst Du das mit Parametern erledigen?

solche Konstrukte wie

Code:

sqltext:='select adresse from tabelle1 where vorname='+form1.edit1.text+';'

sind natürlich tödlich.

und auch soetwas kommt auch nicht in die Tüte:

Code:

sqltext:='select adresse from tabelle1 where vorname='+Listbox1.items[listbox1.selected]+';'

Gruß
K-H

[alzaimar]

Zitat von p80286:

wie willst Du das mit Parametern erledigen?

Zur Laufzeit parametrisierte Queries zuweisen, die Datentypen der Parameter definieren, parametrieren und ab die Luzie.

[p80286]

Zitat von alzaimar:

Zitat von p80286:

wie willst Du das mit Parametern erledigen?

Zur Laufzeit parametrisierte Queries zuweisen, die Datentypen der Parameter definieren, parametrieren und ab die Luzie.

Äh wie soll das dann aussehen?
Gruß
K-H