Mir fällt nichts ein, was gegen den Import direkt auf dem Server spricht (außer, wie gesagt, das Teil ist eh schon 24/7 überlastet).
Allein die reine Übertragung der Datei zum Server als Zipfile spart an der Stelle grob 90% Volumen / Zeit. Klar geht es heute schneller durchs Netz als vor 5 Jahren, rechnet man den Upload beim Kunden und die üblichen asynchronen Übertragunsraten mit, macht es schon einen ziemlichen Unterschied. Das kann man dann noch hochrechnen, wenn die Sache häufiger stattfindet.
So einen Vorgang überhaupt per
XML zu realisieren ist dennoch fragwürdig. Ich hatte in dem Bereich auch schon diverse Diskussionen mit Kunden. "Ja aber
XML ist doch so flexibel". Ja, klar, aber Flexibilität hat ihren Preis. Der
XML Overhead dürfte je nach Modell zwischen 25-50 % Datenvolumen liegen. Die Komplexität des Parsings eines Riesenobjekts ist halt was anderes, als bei einem Zeilen orientierten Format. Irgendwo dazwischen würde ich JSON ansiedeln.
Apropos Flexibilität:
XML bietet zwar eine enorme strukturelle Flexibilität inkl. Typen und Validierung, aber an der Stelle kann man sich auch wieder schnell ins Knie schießen, weil es dank der Möglichkeiten auch unheimlich viele Fallstricke gibt. Wahrscheinlich ist nichts so nervig, wie eine pingelige
XML Verarbeitung. Codierung, Escaping und am Ende handgemachte Fehler (hand coded
XML processing) mit irgendwelchen seltenen Artefakten, wo Elemente nicht geschlossen werden, wenn Vollmond ist oder sowas, da kommt keine Freude auf.
Also
XML Import lieber ausschließlich dann, wenn es ein vollautomatisierter Prozess ist, ohne humanoiden Eingriff und mit guten, bewährten (also viel benutzten und ständig gepflegten) Libs.
ETL:
Die Vorstellung in 2GB
XML per Code rumzuhampeln, krasse xpath Filter und Suchen zu bemühen und unübersichtliche, case und if Romane zu verfassen, Datensuche, Abgleich, Löschung, Ergänzung durchzuführen ist für mich absolut unterirdisch.
Lieber wie completeStranger schrieb: Alles importieren (Importieren = in die Datenbank, nicht in die Produktivtabellen). Dann schön bequem und effizient mit
SQL verarbeiten. Nichts wird schneller, robuster und zuverlässiger sein, versprochen.
Vielleicht wiederhole ich mich, aber das ist streng genommen nicht ETL, sondern eher LET oder LTE. Erst Laden (in die
DB!), dann Extrahieren, Transformieren. Früher, als
DB Ressourcen relativ langsam und teuer waren, hat man nur lieber handgestreichelte Daten ins System importiert. Heute hat man einerseits mehr Power und Ressourcen, andererseits ist der Abgleich auch kleiner, externer Datenmengen mit einer xTB großen
DB ziemlich ressoucenintensiv.