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.