Große xml Dateien importieren

[completestranger]

Zitat von Keldorn:

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"

[freimatz]

Zwischenfrage: wieso SAX? Kann eine moderne DB wie MSSQL nicht direkt die XML importieren? Vielleicht muss man die XML noch ein bischen umformatieren. Aber dazu gibts doch sicher heutzutage viele Tools - oder nicht?

[jobo]

Ich hätte jetzt auch mal "direkter DB Import" gerufen.
DB können das, limitierend sind da eher noch die Ausgangsdateigrößen von >2GB.

Ich vermute, dass Parsing auch unterschiedlich spannend ist. Sind es gigantisch große Objekte in XML oder sind es einfach nur viele kleine Records.

Was ich nicht verstehe am "Import", wohin, wenn der TE keine DB will oder zumindest lieber vermeiden.

Allein wegen der Größe und den schon erkennbaren Schwierigkeiten scheint es mir nicht empfehlenswert lokal mit einer 2GB XML Datei zu arbeiten oder dann mit 2 davon, wenn eine abgeglichen werden soll. Lieber alles in die DB und zwar direkt vom Server importieren lassen, statt die GB noch lokal durch ein Programm zu jagen.

[Blup]

Zitat von jobo:

Ich hätte jetzt auch mal "direkter DB Import" gerufen.
DB können das, limitierend sind da eher noch die Ausgangsdateigrößen von >2GB.

Das ist aber nicht die Aufgabe eines Datenbankservers, sondern höchstens von Tools die der DB-Hersteller zusätzlich liefert. Es ist wahrscheinlich einfacher sein eigenes kleines DB-unabhängiges Tool zu bauen, das die XML in eine SQL-Datei (Skript) wandelt, als sich auf eine bestimmte DB mit einem passenden Tool festzulegen. Die Übermittlung von einem GB-SQL-Skript an den Server sollte bei heutiger Netzwerkgeschwindigkeit nur ein par Sekunden dauern. Wichtiger scheint hier die Verarbeitungsgeschwindigkeit des Servers.

[jobo]

Zitat von Blup:

Zitat von jobo:

Ich hätte jetzt auch mal "direkter DB Import" gerufen.
DB können das, limitierend sind da eher noch die Ausgangsdateigrößen von >2GB.

Das ist aber nicht die Aufgabe eines Datenbankservers,...Die Übermittlung von einem GB-SQL-Skript an den Server sollte bei heutiger Netzwerkgeschwindigkeit nur ein par Sekunden dauern. Wichtiger scheint hier die Verarbeitungsgeschwindigkeit des Servers.

Ja, mag sein, wahrscheinlich gibt es viele DB Server die 24/7 so perfekt ausgelastet sind, dass sie vielleicht nicht viel mehr vertragen. (Abgesehen davon, dass sie am Ende trotzdem die Daten aufnehmen müssen) Doch wenn es um massive DV geht und gängige Tools mehr oder weniger zusammenbrechen, wenn es nur um das Parsing geht, gibt es vielleicht ein Problem oder?
Ein DB Server sollte überhaupt kein Problem haben, mit GB Daten umzugehen, das sehe ich weniger als Hoffnung, denn als Statement und eine komprimierte GB XML Datei ist zur Netzübertragung noch besser geeignet. Also solche kann sie vielleicht sogar gleich in den Import / DB gestreamt werden.
Und wie soll ein Prozess, bei dem GB Daten auf einem (einzigen) System verarbeitet werden (Import, Parsing, Verteilung / ETL) schneller werden dadurch, dass man einen (entfernten) Client zusätzlich ins Spiel bringt, der die GB Daten dann atomisiert und 1000e bis Millionen von Einzelschritten über Netz ausführt und dabei wahrscheinlich kaum Datenoverhead spart.

Und apropos Zuständigkeit, es gibt gute, kostenlose Tools zur Zerlegung großer XML Dateien, das braucht man auch nicht selbst zu schreiben.

[completestranger]

Zitat von Blup:

Zitat von jobo:

Ich hätte jetzt auch mal "direkter DB Import" gerufen.
DB können das, limitierend sind da eher noch die Ausgangsdateigrößen von >2GB.

Das ist aber nicht die Aufgabe eines Datenbankservers, sondern höchstens von Tools die der DB-Hersteller zusätzlich liefert. Es ist wahrscheinlich einfacher sein eigenes kleines DB-unabhängiges Tool zu bauen, das die XML in eine SQL-Datei (Skript) wandelt, als sich auf eine bestimmte DB mit einem passenden Tool festzulegen. Die Übermittlung von einem GB-SQL-Skript an den Server sollte bei heutiger Netzwerkgeschwindigkeit nur ein par Sekunden dauern. Wichtiger scheint hier die Verarbeitungsgeschwindigkeit des Servers.

ja und das lesen von großen XMLs/JSONs mit mehreren hunderttausend "zeilen" dauert in SQL auch nur wenige sekunden. und es ist DEFINITIV aufgabe SQLs, sonst würde die ISO/IEC es nicht im standard aufnehmen

https://en.wikipedia.org/wiki/SQL:2003 - XML-related features (SQL/XML)
https://en.wikipedia.org/wiki/SQL:2016 - JSON

man sollte sich gegen neue dinge nicht wehren, besonders wenn der bedarf vorhanden ist. jede mir bekannte VERNÜNFTIGE SQL server software unterstützt XML/JSON

MSSQL: T-SQL
XML: https://docs.microsoft.com/en-us/sql...xml-sql-server
JSON: https://docs.microsoft.com/en-us/sql...l-server-ver15

ORACLE: PL/SQL
XML: https://docs.oracle.com/cd/B19306_01...9/xdb04cre.htm
JSON: https://docs.oracle.com/database/121/ADXDB/json.htm

PostgreSQL: PL/pgSQL
XML: https://www.postgresql.org/docs/9.1/functions-xml.html
JSON: https://www.postgresql.org/docs/9.3/functions-json.html

MariaDB: SQL/PSM
XML: https://mariadb.com/kb/en/load-xml/
JSON: https://mariadb.com/kb/en/json-functions/

etc. pp.

einen SQL server mit mehreren tausenden befehlen zu bombardieren ist falsch, solange/sobald man mit wenigen befehlen zum gleichen ergbnis kommt