ADO Command mit mehreren Inserts

[Jelly]

@Dominik: Aus genau den Gründen versuch ich ja die ganze Zeit eine geschicktere Datenbankstruktur zu forcieren. 10000 Records pro Sekunde sind eine Menge, und gerade wenn bereits zisch Millionen Einträge in einer Tabelle sind, geht das Hintufügen von weiteren Records nicht gerade schneller, geschweige denn spätere Select Abfragen. Egal wie es ist... Aber eine Tabelle anlegen wo man eifach Messpunkt für Messpunkt hinten ranklatscht halt ich definitiv für unpassend.

[alzaimar]

Ich hatte mir die Eckdaten (#Messdaten, #Messpunkte) nicht angeschaut, aber mit BCP oder egal welchem System wird das wirklich auf Dauer Nichts.
Ich habe zwar eine DB, die das kann (Schreiben mit 80.000 - 500.000 Messpunkte pro Sekunde), aber das ist doch nicht die Lösung.

Wir müssen vorher nochmal die o.g. Diskussion aufwärmen. Hier stimmt wirklich etwas nicht. Ich kann mir kein Szenario vorstellen, bei dem man alle 10.000 Messunkte jede Sekunde speichern muss. Die Granularität, also das je Sekunde gemessen wird, kann ich mir gut vorstellen, i.a. ist es aber so, das nur besondere Ereignisse (Statuswechsel) geloggt werden müssen. Insofern wäre es ratsam, je Datentabelle (oder alles in Eine, eigentlich wurscht) eine Spalte 'DateTime' (auf die Sekunde genau) anzulegen und nur diese 'besonderen Ereignisse' abzulegen.

Hier oder im DF hatte ich vor einigen Monaten ein Problem, bei dem *zu Verifizierungszwecken* mal ALLE Messwerte gespeichert werden mussten (20GB pro Tag). Einfach, um die Verdichtungsheuristik, die dann zum Einsatz kommen soll, zu testen. Da waren es knapp 200.000 Daten pro Sekunde. Das bekommt man mit einem schnellen Rechner, B-Baum, Cache und Speicherung in 8k-Blöcken (System page) ganz gut hin. Über den B-Baum hat man dann auch eine schnelle Recherchemöglichkeit. Aber hier sehe ich das nicht. Hier sollte verdichtet und nur Veränderungen gespeichert werden. Alles Andere ist falsches Design (oder man erklärt nochmal kurz, WARUM wirklich ALLE Daten gespeichert werden müssen).