Nachdem ich mich aus diversen Gründen länger nicht damit befassen konnte, hab ich heute mir das heute nochmal angeschaut. Da ich mir keine Hoffnungen mehr mache die Daten direkt per Datenbank auszulesen wurden direkt die Eingeweide der Binärdateien seziert...
Nach etwas Vorfiltern mit strings und sed konnte ich den Aufbau recht schnell rauslesen:
Code: Alles auswählen
Katalognr ("Bild-/Positionsnr")
Modellnr
Teilenr
(Modellvariante von Modellnr zu der diese Teilenr passt)
(Modellvariante)
(Teilenr)
(Modellvariante)
...
Dabei können mehrere Teilenummern unterhalb der Modellnr gelistet sein die jeweils wieder mehrere (oder keine) Modellvarianten untergeordnet haben. Eingeleitet wird aber immer mit einer Katalognr und Modellnr.
Problematisch sind nur einige Katalognr-Einträge (ca 2-3%) auf die direkt und nur eine Teilenr folgt und sonst kein anderer Bestandteil. Diese verwerfe ich aktuell - lieber ein paar "fehlende" Einträge als falsche. Zudem scheinen diese Katalognr/Teilenr-Beziehungen redundant zu sein und tauchen an Anderer stelle mit allen Daten nochmal auf.
Nach einigem Kopfzerbrechen wie ich das Variable auftreten der Teilenummern und Modellvarianten am besten behandle war irgendwann auch ein relativ simpler Algorithmus in AWK geschrieben mit dem auch die Patterns für die verschiedenen Nummern an mehreren Dateien getestet werden konnten.
Nachdem 10 Testdateien (von knapp 100...) damit erfolgreich in eine Normalform dargestellt werden konnten habe ich heute Nachmittag fix einen gruseligen Prototypen/POC/Wasauchimmer in Perl zusammengeschustert der die Dateien direkt parst, Werte in Variablen ablegt und daraus UPDATE/INSERT operationen zusammensetzt die per DBD:Cassandra in 3 Tabellen mit unterschiedlicher Struktur gepumpt werden (per "do" weil ganz faul und noch nie wirklich mit Perl:DBI gearbeitet
)
Die 3 Tabellen werden den typischen Abfragemustern bzw Gliederungen der Daten gerecht.
Das ganze funktioniert soweit, ist nur noch hoffnungslos "Langsam": Eine Datei erzeugt ca 30000-35000 UPDATE/INSERTS, die knapp 11000 Datenbankzeilen (3500-4000 je Tabelle) erzeugen und das Script benötigt dafür ~1:30 min mit consistency "LOCAL_QUORUM".
Allein schon das preparen der Datenbankqueries anstatt alles sofort per "do" auszuführen wird das ganze erheblich beschleunigen, weil die tatsächliche Anzahl an DB-Operationen mindestens halbiert wird. Wenn ich zudem nicht seriell parse sondern zuerst (ggf batchweise - die ADABAS-Daten sind grob nach Modellcode sortiert) zusammengehörendes in ein entsprechendes array/hash-gebilde pumpe, kann ich auch hier die writes an der DB verringern, einfach weil sonst viele Zeilen mehrfach geschrieben werden müssten.
Unterm Strich war das ganze bisher aber deutlich schmerzfreier als die Suche nach Informationen und (freier) Software für adabas
Ich würde ja zu gerne mal das (fertige) Script auch auf die MSSQL-DB loslassen. Ich befürchte nur dass ich dann erstmal keine Ruhe mehr habe wenn der Server abraucht
