Große xml Dateien importieren

[Keldorn]

Danke für die rege Diskussion, hilft mir

Grundlegend hatte ich eben so ein Tool im Kopf. Das sollte sich um den automatischen import und updates kümmern und dann eben später eine DB aufbauen. Ich war der Ansicht, dass ich die Daten erstmal intern halte und dann halt bei Bedarf die DB aufbaue. Und hier dann auch unabhängiger vom DB-Zielsystem bin.
Problem ist halt auch der unschöne Aufbau, die Tabellennamen heißen nur z.B. „T10000“ und das Programm sollte die auch besser & lesbarer anlegen: „T1000-Beschreibung“.

Select T10000.xyz
…
From T10000
Where T1000.blub = T20000.blub etc
Liest sich irgendwie überhaupt nicht.

Beim import filtere ich auch bestimmte und zu alte Daten raus, für meine Zwecke brauch ich z.B. keine 5 Jahre alten Daten, die die eigentlich DB auch nur aufblähen.
Bei den updates komme ich halt auch nicht an dem Punkt vorbei, dass mit jedem record erstmal geschaut werden muss, was mit ihm passiert (insert, update, löschen).

Grundlegend ist auch alles dabei, das meiste sind aber schon viele kleine records mit mehreren strings[10].

Deswegen auch die clientdatasets, da hier schon die gleiche Struktur vorliegt. Das hat ja auch geklappt, die CDS können schon die großen Daten halten, nur nicht speichern (insuffizient memory). Das ging halt nun nicht, Pech und google bringt hier auch nicht viel außer es geht nicht.
Werde bei Firedac bleiben und die Daten nun direkt in der ZielDB halten.
Für den eigentlichen import schaue ich mir die Hinweise intensiver an, danke

Ich muss erstmal wieder fit werden und werde mich sicherlich mit paar Punkten nochmal melden

[completestranger]

Zitat von Keldorn:

Beim import filtere ich auch bestimmte und zu alte Daten raus, für meine Zwecke brauch ich z.B. keine 5 Jahre alten Daten, die die eigentlich DB auch nur aufblähen.
Bei den updates komme ich halt auch nicht an dem Punkt vorbei, dass mit jedem record erstmal geschaut werden muss, was mit ihm passiert (insert, update, löschen).

und warum sollte das GEGEN eine SQL lösung sprechen? die dinger heißen nicht umsonst relational DATAbase management system (RDDBMS).
die daten liegen dann z. b. in einer temp-tabelle oder einfach in einer "staging"-tabelle, da kannst du dann filtern mit der WHERE-clause was die daten hergeben.
deine INSERTs, UPDATEs und DELETEs kannst du dann auch machen aka

Code:

delete from produktiv
from produktiv p
join staging s on s.primarykey = p.primarykey
where s.veraltet = 1

hab n zweieinhalb menütiges video erstellt in dem eine 330 mebibyte JSON mit fast 320k datensätze in ~ 55 sekunden verarbeitet wird
* datei in stream laden
* in mssql server schieben
* im mssql server verarbeiten
https://1drv.ms/u/s!AryujEYLwnlNgXQq..._0dzp?e=EbYCFL

[jobo]

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.

[Keldorn]

danke, ich schau mir das alles tiefgründig an