csv automatisch umbauen

[jackx]

Hallo, ich bekomme von einer Software eine csv geliefert die nich das Format hat welches ich haben möchte.

Derzei steht in der ersten Zeile ein Wert den ich nich verabeiten kann. Dieser soll durch andere Werte ersetzt werden und das automatisch. ist sowas machbar?

Ablauf:

Generieren der csv, ablegen an einem Speicherort. Einlesen der csv(womit???wie???) Verarbeitung, löschen BZW ERSETZEN der ersten Zeile.

Ziel der Sache: Automatisches Einlesen von Adressdaten oder Sendungsdaten in UPS World-Ship....der Support dort kann mir nicht helfen!

das ganze muss nicht in einer Datenbank laufen....wenn das Thema hier nicht passt bitte verschieben.

[flashpixx]

Eine CSV Datei ist im Grunde ein unstrukturiertes Datenformat, wenn Du dieses ändern musst, pass den Export an oder schreibe ein Programm in einer Sprache Deiner Wahl, dass die CSV Datei entsprechend umstrukturiert.

Ich raten dringend dazu, dass man von so einem Format dringend Abstand nimmt, denn es macht letztendlich mehr Probleme. Ich rate zu einer Datenbank oder XML mit Validierung durch XSD

[127.0.0.1]

Ich raten dringend dazu, dass man von so einem Format dringend Abstand nimmt, denn es macht letztendlich mehr Probleme. Ich rate zu einer Datenbank oder XML mit Validierung durch XSD

joah, für kleine aufgaben und simple logs reicht auch csv.... man muss ja nicht gleich die dicken geschütze ausfahren. so ein csv lässt sich zur not auch mit dem notpad öffnen. ne datenbank nicht.

ansonsten hats flashpix ja schon gesagt: bau dir nen script, lies die csv zeilenweise ein und, entferne/verändere die unpassenden passagen und speicher die veränderten strings in ne neue datei. mit vbs sollten das ca. 10 zeilen sein, also ein überschaubarer aufwand.

[lilith2k3]

man muss ja nicht gleich die dicken geschütze ausfahren. so ein csv lässt sich zur not auch mit dem notpad öffnen. ne datenbank nicht.

Alles ist besser als CSV. Insofern gebe ich *pixx recht. Man könnte notfalls auch JSON nehmen - soll ja g'rad in Mode sein

Einlesen der csv(womit???wie???) Verarbeitung, löschen BZW ERSETZEN der ersten Zeile.

Schreib' Dir ein Shell-Skript in bashrubypythonperlvbsweißichnicht.

[raiserle]

Kanonen und Spatzen!

Klar definierte Schnittstelle: Warum soll da keine CSV reichen?

Es zu allgm. zu sagen, dass CSV ein schlechtes Format ist, um Daten auszutauschen - geht nicht!

Excel/lib-open-Office/... - Makro wären auch noch möglich

vG

[flashpixx]

Klar definierte Schnittstelle: Warum soll da keine CSV reichen?

Man kann CSV nicht abstrakt validieren, d.h. ich muss Code schreiben, um die Struktur zu verarbeiten bzw. zu prüfen ob sie korrekt ist. Bei XML mit XSD kann ich die Validierung automatisiert erledigen mit Hilfe von XSLT kann ich dann die XML beliebig transformieren. Eine Veränderung der Struktur der CSV zieht somit automatisch eine Veränderung des Codes mit sich. Codepflege ist aufwendig und fehleranfällig. Bei einer XML wäre hier lediglich eine Anpassung der XSLT notwendig, um eine neue Version der CSV zu verarbeiten. Mit Strukturen wie XML, XSD und XSLT ist die Pflege deutlich einfacher und der Code erhält eine höhere Abstraktion. Analoges gilt natürlich für JSON. Für die XML / JSON Verarbeitung gibt es entsprechende Bibliotheken, die seit Jahren getestet und optimiert sind, so dass auch die Fehleranfälligkeit weniger sein wird. Für einen Import dieser Daten muss dann lediglich die XML via XSD validiert werden, damit ist direkt möglich zu prüfen, ob die Struktur korrekt ist, nun kann man mit Hilfe von XQuery in den Nodes suchen und muss lediglich über die gefunden Nodelisten iterieren, d.h. hier ist eine deutliche Codereduktion möglich. Falls man das ganze noch weiter abstrahieren will, setzt man eine XSLT dazwischen, die eine Transformation des XML Baumes durchführt. mit Hilfe der XSLT kann man somit unterschiedliche Versionen der XML verarbeiten, so dass die Pflege und Weiterentwicklung des Importes besser wird.

[raiserle]

Und da haben wir wieder das Problem. Kanonen und Spatzen!

Super Erklärung, aber:

Ein Schema anzupassen/erstellen ist also deiner Meinung nach nicht aufwändig - und nicht fehleranfällig?

Nochmal: Allgm. zu sagen, dass CSV nichts taugt - geht eben nicht.

[flashpixx]

Ein Schema anzupassen/erstellen ist also deiner Meinung nach nicht aufwändig - und nicht fehleranfällig?

XSLT Schemata könne mit entsprechender Toolunterstützung auch schon automatisiert erstellt werden, da es letztendlich auch XML ist.

Und da haben wir wieder das Problem. Kanonen und Spatzen!

Nein, das ist definitiv der Deine individuelle Meinung. Wenn ich real durchrechne wie hoch der Zeitaufwand von Anpassung des Codes über den Zeitraum der Nutzung ist und vor allem wenn ich die Metrik (z.B. Halstead / LLOC Metrik) des Importcodes bestimme, dann ist alleine durch die Metrik belegbar, dass CSV die schlechte Wahl sowohl wirtschaftlich wie auch fachlich ist.

Natürlich setzt XML ein höheres Abstraktionsvermögen an den Entwickler voraus und Du magst recht haben, dass man "schnell mal nen CSV Code zusammen hacken kann" (auch diese Argumentation ist mir bekannt). Auch aus meiner Erfahrung kenne ich den Ansatz, dass man lieber CSV nimmt, weil Programmierer das eben mal schnell in 2 Stunden runterhacken und dann wenn was dran ist schnell nachpflegen kann (da wird gerne das "Eh-Da-Prinzip" angewendet). CSV ist somit ein "Dirty-Hack" ohne Struktur.

Man sieht in solchen CSV Importen immer tonnenweise If-Bedingungen, wenn verschiedene Versionen der CSV unterstützt werden müssen, was aber dann zu einer schlechten Metrik führt, da mehr Lines-of-Code produziert werden müssen. Zusätzlich ist keine Typgebundene Struktur der Datenfelder möglich, d.h. es muss manuell konvertiert werden, was letztendlich extrem fehleranfällig ist, wenn in einem Feld in Abhängigkeit von der CSV Version unterschiedliche Typen benutzt werden. Zusätzlich ist ein sehr großes Problem bei CSV das Encoding der Daten, denn häufig wird hier einfach das Default-Encoding verwendet. Gerade bei der Darstellung von Umlauten (UTF-8/16 mit BOM Codierung) entstehen dann sehr interessante Effekte, die dann wieder "manuell" per Code abgefangen werden müssen, was die Metrik weiter verschlechtert.

Natürlich kostet der höhere Strukturaufwand mehr Wissen, aber die Effizienz, die durch Metriken belegbar ist, kann gesteigert werden. Ich kann die Nodes eines XML Baums via XQuery direkt holen (inkl Filter und Sequenzen), mit Hilfe der XSD habe ich Validierung und direkt Typenkonsistent dabei. Ich kann für jede Version, die ich importiere eine eigene XSLT / XSD hinterlegen, so dass ich lediglich nur diese bei einer neuen Version anpassen muss. Ich habe die Möglichkeit die XML Verarbeitung in generische und versionsabhängige Strukturen zu trennen, so dass ich Anpassungen minimieren kann. Zusätzlich ist die Toolunterstützung bei XML sehr gut, bei CSV gibt es keine Toolunterstützung.

Zusätzlich ist die Anpassung eines Schemas / XSLT deutlich einfache, da im Gegensatz zu Code kein Compilieren bzw. Linken notwendig ist. Der Austausch eines Schemas ist letztendlich der Austausch einer einzelnen Datei. Der Austausch von Code kann unter Umständen auch riskant sein, denn es müssen die Abhängigkeiten der Codestrukturen beachtet werden (Funktionssignaturen etc), somit ist die Anpassung eines Schemas schneller und nicht so fehleranfällig.

Die Aussage, dass mit Kanonen auf Spatzen geschossen wird, ist definitiv falsch. Wenn man CSV einsetzt, dann ist das Kind sprichwörtlich in den Brunnen gefallen, denn das ist definitiv ein Fehler im Designkonzept, dass dies natürlich dann hohen Aufwand zur Korrektur bedeutet, ist klar. Würde man aber zu Beginn der Entwicklung eben auf XML Technologie setzen und darauf dann auch das Design aufbauen, wäre für einen CSV Export lediglich nur der Entwurf einer passenden XSLT notwendig, d.h. von XML nach CSV zu kommen ist einfach, umgekehrt dagegen schwer. Damit ist der Export der Daten direkt wesentlich generischer und damit auch flexibler. Wenn jemand CSV haben, dann kann er sich diese erzeugen. Wenn jemand HTML möchte, dann geht auch das; mit CSV nicht möglich.

Eine fehlerhafte Planung wird man niemals wieder ohne bzw. mit wenig Aufwand korrigieren kann. Der Designfehler ist letztendlich dadurch gegeben, dass eben ein unstrukturiertes Datenformat vorliegt. Bekomme ich eine CSV ist es mir nicht möglich zu validieren, ob ich sie richtig gelesen habe. Bei XML ist dies möglich, da ich die XSD als Entwickler sogar zentral im Web ablegen kann. Das Argument bezüglich der Datengröße ist heute kaum relevant, da genügend Bandbreite zur Verfügung steht (eine Ausnahme mögen hier numerische / vektorielle / Matrizen / Hypercubes sein, aber davon gehe ich jetzt nicht aus).

Generell gilt aber, die Struktur der Daten muss abstrakt überprüfbar sein.

[dr.dimitri]

Zusätzlich ist die Toolunterstützung bei XML sehr gut, bei CSV gibt es keine Toolunterstützung.

Jedes ETL Tool beherrscht die Transformation von csv in irgendwas und umgekehrt.

[lilith2k3]

Sagen wir es einfach: CSV ist kein Format sondern ein Zustand

[flashpixx]

Jedes ETL Tool beherrscht die Transformation von csv in irgendwas und umgekehrt.

Jain ETL ( ETL-Prozess ) sind zwar toolgestützte Prozesse, aber diese kann ich nicht flexibel in der Anwendung einbauen. Bei XML kann ich einfach durch eine XSLT Komponente den Transformationsprozess automatisiert durchführen (und das auf jedem System, da XML / XSLT Bibliotheken heute fast überall vorhanden sind). Z.B. hätte ich jetzt kein ETL Tool auf meinem OSX oder Linux direkt zur Verfügung, womit ich Transformieren kann. LibXML ist aber bei mir auf beiden System vorhanden und ich kann sie direkt entsprechend in meiner Software anbinden (analog MS XML via COM) [mal von der Lizenz und Nutzung des ETL Tools in eigenen Programmen mal abgesehen].

Auch die Aussage, dass das ETL Tool die "Transformation" beherrscht ist, halt ich für sehr gewagt, denn das ETL Tool setzt das Wissens des Users voraus, d.h. der User muss wissen in welchem Feld welcher Typ der Daten steht und wie diese zu interpretieren ist. Bei XML benötige ich diese Information nicht, da sie durch die XSD definiert ist, die mir zentral via URL vom Entwickler bereit gestellt werden kann. Wie man das so schön beim so genannten DTA (Datenträgeraustausch) hat(te), dass man seitenweise in Papierform die Definition der CSV bekommt, diese dann ggf in ein ETL Tool oder in Code übertragen muss, entfällt bei XML.

ETL sehe ich aber nicht im Sinne von CSV, sondern es beschreibt den Vorgang der der Datenübertragung und -transformation, d.h. in einem ETL Prozess würde durchaus XML / XSLT verwendet werden können. Die Tools selbst bietet natürlich für Altsysteme auch den CSV Import an. Bei CSV kann ich die Transformation in keiner Weise "abstrakt" im Sinner einer Modelltransformation beschrieben werden, da bei CSV die Strukturinformation nicht an die Daten gebunden ist. Strukturinformation und Daten sind bei CSV völlig unabhängig, die Verbindung muss zwingend der Benutzer machen.

[dr.dimitri]

Z.B. hätte ich jetzt kein ETL Tool auf meinem OSX oder Linux direkt zur Verfügung, womit ich Transformieren kann

Naja, diese Argumentation ist jetzt etwas dünn. Wenn entschieden wird, dass z.B. Informatica verwendet wird, dann wird das eben bereitgestellt bzw. existiert schon. Wir reden ja von einer produktiven Unternehmenslösung die mit Daten zurecht kommen muss, die von Dritten bereitgestellt werden. Da hilft es wenig, die Vorteile einer XML Schnittstelle aufzuzählen, wenn es eben keine XML Schnittstelle gibt.

Im übrigen halte ich eine Flat File Schnittstelle für interne Anwedungen durchaus für sehr flexibel. Wir haben ein selbst geschriebenes (zufällig von mir ) geschriebenes System im Einsatz, welches, je nach gelieferter Version der Dateien ein Mapping drüberlegt und entsprechende SQLs generiert. Das sind eine Handvoll Zeilen PL/SQL Code, und drei Tabellen.

Keine Spur von ständigen IF Abfragen, auf- und abwärtskompatibel, die Validierung übernimmt die Datenbank und schreibt falsche Daten in die Error Log Tabellen.

Sowohl XML als auch Flat Files sind für ihre jeweiligen Zwecke gut zu gebrauchen, wenn man sie richtig einsetzt. Mit beiden kann ich mir unübersichtliche Programme einhandeln die nur noch schwer wartbar sind oder in andere Probleme laufen (z.B. Performance)

[raiserle]

Und wenn du noch so sehr auf dein XML pochst:

Du hast doch schön dargelegt, dass CSV schnell runtergehackt ist. Stimmt! - Und genau deswegen wird es eingesetzt.

Nicht jeder will an seiner Datenstruktur etwas ändern.

Oder muss gar den Code ändern, weil ein Fehler drin ist.

Daten müssen nicht transformiert werden.

Daten die aus einem System/Software kommen sind bekannt - und wie sie in ein anderes System müssen, ist auch bekannt.

Ich sehe hier den Nutzen nicht. Und dementsprechend die allgm Aussage: CSV geht nicht! als nicht treffend.

Anwendung!

Alles was du zu XML gesagt hast, ist richtig:

Aber weder habe ich unser PDM-System, ERP-System geschrieben, noch habe ich Einfluß, wie die Daten da rauspurtzeln (CSV).

Aber was klar ist, das ich Bsp: eine Stückliste habe, die nun mal eine feste Struktur hat.

Die enthaltenen Daten können nur richtig sein. Also PDM -> ERP per csv.

Oder würdest du dann lieber den Weg gehen, auf den CSV,ex-import zu verzichten - und einen Menschen die Daten übertragen lassen. Denn das wäre dann der einzige Weg.

Immer auch mal den Anwendungsfall betrachten und nicht allgm. die Aussagen treffen.

[flashpixx]

Im übrigen halte ich eine Flat File Schnittstelle für interne Anwedungen durchaus für sehr flexibel.

Da schließe ich mich an, wenn das "intern" ist, kann man das machen bzw. wenn der Zweck begrenzt ist.

Keine Spur von ständigen IF Abfragen, auf- und abwärtskompatibel, die Validierung übernimmt die Datenbank und schreibt falsche Daten in die Error Log Tabellen.

Auch dem stimme ich zu, aber Du hast ja dabei eine knapp definierte Anwendung. Ich habe in meiner Ansicht z.B. den alten DTA aus Einwohnermeldeämtern z.B. für die GEZ / Kirchen etc im Kopf.

Und wenn du noch so sehr auf dein XML pochst:

Ich poche nicht auf XML, sondern ich poche auf einer strukturierten & überprüfbaren Datenstruktur. Du kannst da auch JSON oder HDF nehmen.

Daten die aus einem System/Software kommen sind bekannt - und wie sie in ein anderes System müssen, ist auch bekannt.

[/quite]

Das ist denke ich eine falsche Prämisse, denn kein System ist für alle Ewigkeiten fix, d.h. Anpassungen sind notwendig.

Das ist aber genau meine Aussage bezügl des Designfehlers. Wenn Du aus einem ERP z.B. Stücklisten raus müssen, dann gehört zu einem Stück z.B. ein Name, ein Preis, ein Volumen etc. Name ist definitiv ein Text, Preis und Volumen eine Zahl. In einer CSV ist dies nicht definiert, da ist alles ein String.

Die Liste, die erzeugt wird, ist nicht validierbar, d.h. ich kann z.B. mit einem Texteditor aus einem Preis einen String machen, dann tritt bein Import das Problem auf bzw. je nach Import werden falsche Daten importiert. Bei 1000enden Datensätzen wird kein Mensch diesen Fehler bemerken.

Via XML / XSD würde mir das System direkt den Fehler liefern, dass der Datentyp inkorrect ist.

Ich weiss durchaus wovon ich spreche, denn ich habe vor einigen Jahren, genau so etwas gemacht. In einem System wurde auch primär per CSV gearbeitet. Es wurde auch die Meinung vertreten dass CSV "schneller" und "einfacher" ist. Mit XML haben wir eine deutliche Codereduzierung erreicht und deutlich die Qualität der Daten sowohl beim Ex- wie auch beim Import steigern können.

[allesweg]

Ein weiterer Schwachpunkt von CSV ist der separierende Character. Sobald dieser in der Liste vorkommt und das nicht sauber abgefangen wurde, knallt's.

[dr.dimitri]

Ein weiterer Schwachpunkt von CSV ist der separierende Character. Sobald dieser in der Liste vorkommt und das nicht sauber abgefangen wurde, knallt's.

Das gilt auch für XML wenn ein reserviertes Zeichen nicht richtig maskiert wurde.

[afo]

Das gilt auch für XML wenn ein reserviertes Zeichen nicht richtig maskiert wurde.

Nur dass bei XML definiert ist wie das zu erfolgen hat.

[gewünschter_Benutzername]

Schaue dir das mal an: CONVERT - Freeware Program for Data Conversions - Brief description