Hmm... Wenn es performancetechnisch eine Rolle spielt, wie schnell 5000 Inserts sind, dann stimmt was mit meinem Design nicht. Es ist eigentlich immer falsch, 5000 Inserts aus seiner Software heraus zu machen, wenn die Performance wichtig ist. Dann musst Du zu BULK INSERT greifen, bzw. (bei 5000 vermutlich einfacher und schneller) auf Dataset-Parameter (also eine @Tabelle).
Dann machen wir was falsch. Wir inserten Mio-Datensätze in Stunden. Den "Bulk Insert" kann man auch per "normalen"
SQL- nachbilden.
Aber weder das eine noch das Andere wird von
ADO nicht unterstützt (
ADO wird
imho eh nicht weiterentwickelt).
Betrifft AFAIK nur den MS
OLE DB Provider for
SQL Server, nicht den
SQL Server Native Client.
BULK INSERT bekommst Du aber mit einem einfachen ADOCommand hin.
Eigentlich schon - oder jedenfalls fast. Du kannst problemlos mehrer INSERTS zu einem einzelnen "BULK" zusammenfassen.
Wenn Du also Provider vergleichen willst, dann musst Du das schon entweder mit irgend einer Referenz-
DB machen (also z.B.
FB) oder Tests für viele RDBMS schreiben.
Also wir haben das mal mit diversen DBs gemacht (MS
SQL,
MySQL, Oracle).
Die DBs nehmen sich nicht viel. Viel wichtiger ist der eigene Quellcode. Wenn man hier murks macht kann selbst der größer Cluster-Server nix mehr reisen wenn auf
DB-Seite Grundvorrausetzungen wie genügend zugewiesener Speicher und (genügend) schnelle Festplatten dran hängen vorhanden sind. Als wir (vor Jahren) einen Prepared Statement-Cache eingebaut haben und dann noch auf selbstgeschriebenen "Bulk INSERT" umgestiegen sind hatten wir einen gewaltigen Performancegewinn - egal welche
DB.
Bei MS
SQL haben wir die ADOExpress/dbGo rausgeschmissen uns sind aufs
ADO-Interface umgestiegen. Hat hier auch viel gebraucht.