Mache es in
SQL.
Der Grund mal abseits von SQLite, dass ein BatchInsert im Gegensatz zum Update eher mit dem Allokieren von
DB Block einhergeht. Damit muss eigentlich der Treiber ähnlich OLEDB gegen
SQL Server das sich selbst mit der
DB ausmachen. Vor gut 17 Jahren 1 Mio Sätze in ein paar Sekunden.
Auch in dem Fall sind die Batch Inserts und Batch Updates getrennt.
Das Thema ist happig, da du einerseits den Rebuild eines oder mehrer Indexes musst vermeiden, die Array Größe muss mit Allokationshäufigkeit von
DB Blöcken und der Geschwindigkeit abgestimmt sein und Roundtrips sollen minimiert werden. Außerdem macht es zumeist Sinn Einstellungen des
DB Clients selbst in dem Sinne zu frisieren.
Die damit verbundene Methoden früher war zuerst die leeren
DB Blöcke mit den Schlussel zu erzeugen und der Batch Update nachzujagen.
Aus gutem Grund machen das Staging Werkzeuge im Umfeld von Datawarehousing genauso. Je nachdem wie schnell die 'Platte' ist variiert die Größe von solche Arrays ungemein. Ein Konzern hatte mal bei der IBM im Rechenzentrum die Infrastruktur im 'Safe' Mode laufen. Da hatte man Arraygrößern von 10 bis 20k Sätze. Dann haben wir hochdrehen lassen auf 'normal'. Hernach war die Arraysize um das 10 bis 20fache und mehr.
Ein Einflussfaktor wie bei einer kleinen lokalen Oracle
DB oder
SQL Server wäre ein Shared Memory zwischen Client und Server oder über
TCP/
IP (lokal). Nicht umsonst haben Remobjects und WCF solche Channels.
Wir haben früher zumeist Planungsläufte auf ein Quellsystem zurückgeschrieben und Historien aufgebaut.
Im Falle von Remote ist im Stile eines ORM zu optimieren leichter, da ein asynchroner Service in dem Fall Gold wert ist (ala Lightswitch). Wenn man das asynchrone Element in die
DB reinzieht, dann wäre die Antwort ein In-Memory Tabellen resp. ein ein In-Memory Store dessen Inhalt die
DB asynchron persistent macht. Die nächste Stufe wäre wie in deinem Fall von Tabelle auf Tabelle intern in der
DB mit
SQL.
Die ORM sind z.T. ident mit Versant OO-
DB allein um
RTTI angereichert (Telerik) oder GemStone und das dazu passende Smalltalksystem kannte direkt verbunden Objekte resp. Proxyobjekte. Die Vorzüge des ORMs kannte man unter Smalltalk, da du einfach am Morgen eine Collection hast ausgecheckt und die veränderten Objekte am Abend hast persistent gemacht (etwas blumig ausgeschmückt).
Solche Architekturen entspricht eher ein serverseitig gehaltener Object Cache. Bei letztgenannten besteht wieder das Problem der Serialisierung, wenn unterschiedliche Technologien und seien das in Java oder .net implementierte Programme drauf zugreifen, damals in
XML.
Der Vollständigkeit halber angemerkt.
Am Besten direkt per
SQL.
Danke, aber wie? Stehe auf dem Schlauch....
okay, wer "googeln" kann ist klar im Vorteil:
INSERT INTO master SELECT * FROM working [WHERE ....]
Aber vielleicht kennt ja doch noch einer einen "Aurelius" Mechanismus....würde gerne mein
SQL Zeug loswerden....