Große xml Dateien importieren

[Keldorn]

Zitat:

Zitat von completestranger (Beitrag 1503611)

Entweder ich bin blind oder es wurde immer noch nicht geschrieben welches RDBMS zum Einsatz kommt.

dafür habe ich mich noch nicht schlussendlich entschieden.
Welche Bedeutung hätte das für dich?

Aus meiner aktuellen Sicht ist das erstmal zweitrangig, da ich ich ja den Grundbestand UND die updates behandeln möchte. Ziel ist schon, beides per Programm zu importieren. Nicht weiter tiefer geschaut, sicherlich kann ich eine xml auch direkt in ein DBsystem importieren. Da es aber über 150 Einzeldateien sind, beherrscht das keiner. Das hab ich gedanklich erstmal ausgeschlossen.

[Uwe Raabe]

Zitat:

Zitat von Keldorn (Beitrag 1503610)

momentan importiere ich es als Zwischenschritt in normale Clientdatasets, die mit der Größe auch nicht klarkommen :roll:

Was insofern auch nicht verwunderlich ist, da diese ja auch alle Daten im Speicher halten - was bei 1,7 GB XML-Daten ja auch mit einem SAX-Parser nicht unbedingt laufen wird.

Ich würde erstmal versuchen das Memory-Problem mit SAX und dem Schreiben in eine CSV-Datei lösen. Dabei sollte man dann aber auch TStreamWriter anstatt TStringList verwenden.

[Keldorn]

cds: japp, dessen bin ich mir voll bewusst. Eigentliche Datengröße ist ja deutlich kleiner, die xml ist ja durch die <xyz> aufgebläht. Datensätze sind es aber trotzdem genug

[completestranger]

Zitat:

Zitat von Keldorn (Beitrag 1503612)

Zitat:

Zitat von completestranger (Beitrag 1503611)

Entweder ich bin blind oder es wurde immer noch nicht geschrieben welches RDBMS zum Einsatz kommt.

dafür habe ich mich noch nicht schlussendlich entschieden.
Welche Bedeutung hätte das für dich?

Aus meiner aktuellen Sicht ist das erstmal zweitrangig, da ich ich ja den Grundbestand UND die updates behandeln möchte. Ziel ist schon, beides per Programm zu importieren. Nicht weiter tiefer geschaut, sicherlich kann ich eine xml auch direkt in ein DBsystem importieren. Da es aber über 150 Einzeldateien sind, beherrscht das keiner. Das hab ich gedanklich erstmal ausgeschlossen.

Da liegst du meiner Meinung nach gewaltig falsch. Wir importieren maßig, auch bis zu 2.xyz irgendwas GB große XMLs direkt in MSSQL. Es handelt sich dabei um typische EDI Meldungen wie INVOIC, REMADV, DESADV, PRICAT, PRODAT, etc. Die großen Dateien sind in ein paar Sekunden verarbeitet. Es spielt keine Rolle ob es Full- oder Delta-Meldungen sind.

[Sinspin]

Zitat:

Zitat von Keldorn (Beitrag 1503614)

cds: japp, dessen bin ich mir voll bewusst. Eigentliche Datengröße ist ja deutlich kleiner, die xml ist ja durch die <xyz> aufgebläht. Datensätze sind es aber trotzdem genug

Ist das immer XML output oder kannst du das Format auch beeinflussen?
Wenn Du die Daten als auch als CSV bekommen kannst sind erstmal die Dateien kleiner und einfacher, zeilenweise, zu lesen, und verarbeiten lassen sie sich auch deutlich leichter.
Noch besser wäre SQL, selbst wenn es ein anderer Dialekt ist und ein paar Ersetzungen gemacht werden müssen.

[Keldorn]

ich nehm jede Anregung gerne auf, sonst hätte ich ja nicht gefragt ;-)
bin aber erstmal krank :?

Zitat:

Zitat von completestranger (Beitrag 1503637)

Da liegst du meiner Meinung nach gewaltig falsch. Wir importieren maßig, auch bis zu 2.xyz irgendwas GB große XMLs direkt in MSSQL. Es handelt sich dabei um typische EDI Meldungen wie INVOIC, REMADV, DESADV, PRICAT, PRODAT, etc. Die großen Dateien sind in ein paar Sekunden verarbeitet. Es spielt keine Rolle ob es Full- oder Delta-Meldungen sind.

DB sind nicht so meins. ich wollte das perspektisisch über firedac aufbauen, damit ich dort unabhängig(er) bin. als DB wollte ich erstmal interbase probieren.
Mit den Sekunden klingt gut, aber da muss ja auch erstmal was dahinterstehen ;-). wenn es SAX ist, dann halt SAX

die updates sind bei mir etwas schwieriger, da werden Datensätze auch geändert, man bekommt ein i(nsert) d(elete) oder u(pdate) mit. Es ist nicht nur ein reines importieren.

Zitat:

Zitat von Sinspin (Beitrag 1503680)

Ist das immer XML output oder kannst du das Format auch beeinflussen?
Wenn Du die Daten als auch als CSV bekommen kannst sind erstmal die Dateien kleiner und einfacher, zeilenweise, zu lesen, und verarbeiten lassen sie sich auch deutlich leichter.
Noch besser wäre SQL, selbst wenn es ein anderer Dialekt ist und ein paar Ersetzungen gemacht werden müssen.

ich kann das Format nicht ändern, die Daten werden zur Verfügung gestellt. xml ist evtl nicht so unglücklich, es sind ein paar weniger Felder drin, die als string[500] oder string[2000] definiert sind, da sind sicher auch Zeilenumbrüche drin und da gehts beine csv ja schon wieder los;-)

[Blup]

Ich würde erst einmal ein Toll für die Kommandozweile schreiben:
- Lesen einer XML-Datei per SAX
- Ausgabe einer SQL-Script-Datei mit den entsprechenden Inserts (ist auch nicht viel anders als CSV-Datei)
Je nach Datenbanksystem alle par 1000 Datensätze ein "Commit;" einfügen, damit das ganze schneller verarbeitet wird und dem Server nicht der Speicher ausgeht. Dann kann man immer noch überlegen ob man diese Funktion und die Ausführung des Skripts in die eigentliche Anwendung integriert.

[completestranger]

Zitat:

Zitat von Keldorn (Beitrag 1503690)

DB sind nicht so meins. ich wollte das perspektisisch über firedac aufbauen, damit ich dort unabhängig(er) bin. als DB wollte ich erstmal interbase probieren.
Mit den Sekunden klingt gut, aber da muss ja auch erstmal was dahinterstehen ;-). wenn es SAX ist, dann halt SAX

die updates sind bei mir etwas schwieriger, da werden Datensätze auch geändert, man bekommt ein i(nsert) d(elete) oder u(pdate) mit. Es ist nicht nur ein reines importieren.

war nur ein vorschlag. die inserts, deletes und updates sind gar kein problem, weil es dann bereits daten im sql server wären und die lassen sich zusammen-joinen, etc.

[bernau]

Als SAX-Parser werfe ich mal den von Stefan Heymanns in den Ring. Verwende ich seit Jahren (Jahrzehnten).

http://www.destructor.de/xmlparser/index.htm

Dort nach TXMLScanner schauen.

[dummzeuch]

MSXML kann übrigens auch SAX. Ist auch ziemlich schnell, nur das Fehlerhandling ist wie immer bei COM eine Katastrophe, was die übliche Fehlermeldung ja auch schon sagt: "catastrohic failure" ;-)