TMS Aurelius ganze Tabelle kopieren

[noisy_master]

Hallo liebe Gemeinde,

heute hätte ich mal eine Frage zur Nutzung von Aurelius: Ich habe eine SQLIte Datenbank, die ich mit Aurelius "bediene". Ich habe 2 Tabellen dort drin: eine "working" Tabelle, die ich mit Daten befülle, und eine "Master" Tabelle, die quasi als Sammelpool der "Working" Tabellen(mehrerer Clients) dient. Soll heissen: zu (von mir definierten Zeitpunkten) sollen alle Daten aus der "working" Tabelle in die "Master" Tabelle verschoben werden. (Unter BDE habe ich das mit einem Batchmove und einem anschließenden Delete * from working gemacht). Hat irgendwer eine Idee, wie man das mit Aurelius hinbekommt?

Vielen Dank schon mal im voraus!

Gruß
Dirk

[mkinzler]

Am Besten direkt per SQL.

[noisy_master]

Zitat von mkinzler:

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

[TigerLilly]

Aurelius kennt keine Batch-Operationen im herkömmlichen Sinn. Du musst das entweder zeilenweise machen (siehe dazu aber auch 6.14 der Hilfe) und kannst dann die Aureliusklassen nutzen, oder du nutzt die IDBConnection and setzt dort direkt ein SQL Statement ab.

insert into a select * from b
oder
insert into a (a1,a2,a3,a4,...) select (b1,b2,b3,b4, …) from b

[HoppyP]

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.

Zitat von noisy_master:

Zitat von mkinzler:

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