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