Array in csv schreiben

[Sir Rufo]

Zitat von Dejan Vu:

CSV ist solcher Müll, das selbst mein SSMS (SQL Management Studio), welches *CSV* exportieren kann, nicht mit EXCEL klar kommt. Beides auf der selben Maschine installiert. Beides von Microsoft. Gleicher Laden, andere Abteilung. Von wegen 'keine Probleme'

Dabei könnte es so einfach sein einen Dialog davorzuschalten, wo man zumindestens Delimiter und QuoteChar einstellen könnte. Von Zeilenende und Start bei Zeile x würden wir im ersten Step absehen, wir wollen niemanden überfordern, der schon Probleme mit dem Auseinanderhalten von Tablet und Desktop hat

[Dejan Vu]

Eine Firma bekommt Daten von über 40 Zulieferern natürlich per CSV. Die Firma ist eine Quasibehörde und daher ist diese Vereinbarung taufrisch, aus dem Jahre 1976. Seit 10 Jahren wird erst an der Nachfolgespezifikation gearbeitet, also muss die derzeit gültige taufrische Spezifikation noch einige Jahre halten. Also CSV..

40 Zulieferer. Für jeden Zulieferer einen eigenen Dialog. Speichern der Einstellungen bringt etwas, aber nicht viel, weil die Daten manchmal auch per Dienstleister im Ausland (manuell) erfasst werden. Ja. Elektronisch erfasste Daten werden ausgedruckt, ins A.A.Ausland geschickt, dort eingetippt und dann per CSV an die Quasibehörde geschickt. Per FTP. Mal mit Komma, mal mit Semikolon. Oder als WORD-Datei. Willkürlich formatiert. Oder EXCEL. Mal so, mal so.

Aber manchmal wird -höhöhö- der Ausdruck der vormals elektronisch erfassten Daten auch direkt an die Quasibehörde geschickt. Also ca. 500kg Papier. Die werden dann von eigens eingestellten professionellen Abtippern eingegeben. Zweimal. Weil diese Quasibehörde gibt es zwei Mal. Mmf. Grmpfl.

Ich schweife ab. Ich bin nicht mehr bei dem Verein.

Gott.
Sei.
Dank.

Wo war ich? Ach ja. In der Klapsmühle.

Nee, also in einen Importfilter mal einen Eingabe/Konfigurationsdialog einzubauen. Das hat was. Merke ich mir.

[smallie]

Ich versuche mich kurz zu fassen, weil wir OT sind.

Zitat von Dejan Vu:

Eine Firma bekommt Daten von über 40 Zulieferern natürlich per CSV.

Das trifft auf uns auch zu. Manche Zulieferer liefern jeweils für vier oder fünf Kunden, so daß am Ende täglich locker hundert Pakete eintreffen, die aus mehreren Dateien bestehen.

Die größeren Datenlieferungen bringen es täglich leicht auf 100 MB. Da purzeln die Gigabytes.

So - jetzt stell dir vor, das seien alles XMLs. Wieviel overhead würde das bedeuten? Mir fehlt die Erfahrung das einzuschätzen - ich tippe auf das fünffache oder zehnfache Volumen. Bitte korrigieren, falls ich daneben liege. In jedem Falle ist das als Kostenfaktor wegen Speicherung und Sicherung nicht zu unterschätzen, zumindest in der Liga, in der wir spielen.

Es gibt noch einen zweiten Aspekt: csv-Dateien harmonieren gut mit relationalen Datenbanktabellen. Mit direct load sind die Daten im Nu in der Datenbank, wenn normalisierte Stammdaten in eigenen Tabellen vorgehalten werden müssen. Erst ein XML zu parsen, nur um es letztlich doch in relationale Tabellen zu stecken, wäre ein unsinniger Aufwand, oder?

Zitat von Dejan Vu:

40 Zulieferer. Für jeden Zulieferer einen eigenen Dialog. Speichern der Einstellungen bringt etwas, aber nicht viel, weil die Daten manchmal auch per Dienstleister im Ausland (manuell) erfasst werden. Ja. Elektronisch erfasste Daten werden ausgedruckt, ins A.A.Ausland geschickt, dort eingetippt und dann per CSV an die Quasibehörde geschickt. Per FTP. Mal mit Komma, mal mit Semikolon. Oder als WORD-Datei. Willkürlich formatiert. Oder EXCEL. Mal so, mal so.

Naja. Das ist kein Problem, das der csv-Datei angelastet werden kann. Hier hapert es an der Organisation. Andersherum gesagt: traust die Leuten, die kein wohlgeformtes csv zu Wege bringen zu, daß sie gültige XMLs liefern?

Zitat von Dejan Vu:

Aber manchmal wird -höhöhö- der Ausdruck der vormals elektronisch erfassten Daten auch direkt an die Quasibehörde geschickt. Also ca. 500kg Papier. Die werden dann von eigens eingestellten professionellen Abtippern eingegeben. Zweimal. Weil diese Quasibehörde gibt es zwei Mal. Mmf. Grmpfl.

Ich hab' mich schon mehrmals gefragt, warum es hier im Forum keinen daily-WTF-Thread gibt. Das wäre ein schöner Startbeitrag.

Zitat von Dejan Vu:

Nee, also in einen Importfilter mal einen Eingabe/Konfigurationsdialog einzubauen. Das hat was. Merke ich mir.

So etwas baue ich gerade. Ich sollte das mal vorstellen. Zu einem bestimmten Ansatz käme mir Manöverkritik ganz gelegen, bevor ich das festzurre.

[Dejan Vu]

Overhead? Das ist doch vollkommen egal. (Validiertes) XML ist weltweit identisch. Du kannst kein wohlgeformtes und validiertes XML bekommen, was Dir plötzlich Probleme macht. Wohl aber eine vollkommen zerschurbelte CSV-Datei.
Speicherplatz? Zip das Zeugs.

Zitat von smallie:

Es gibt noch einen zweiten Aspekt: csv-Dateien harmonieren gut mit relationalen Datenbanktabellen. Mit direct load sind die Daten im Nu in der Datenbank

Genau, weil es ja nur ein Format gibt und einen Trenner...

Zitat:

Andersherum gesagt: traust die Leuten, die kein wohlgeformtes csv zu Wege bringen zu, daß sie gültige XMLs liefern?

Es gibt kein 'wohlgeformtes CSV'. Es gibt wohlgeformtes XML (was mir auch egal wäre) und es gibt validiertes XML (gegen ein Schema).

Wenn deine Zulieferer alle mitspielen und wissen, was sie tun, können sie auch proprietäres Binärformat schicken. Jetzt schicken sie ein proprietäres Text-Format, aber wenigstens spielen sie mit.

PS: XML in einen Server geht genauso schnell und das Aufdröseln in Tabellen auch. Sind halt ein paar Zeilen mehr. Einmalig.

Aber jedem das Seine. CSV hat jedenfalls imho in der professionellen Softwareentwicklung und im Datenaustausch, der etwas auf sich hält, nichts verloren. Das ist nicht abwertend, sondern in meinem Umfeld so.

[smallie]

Zitat von Dejan Vu:

Speicherplatz? Zip das Zeugs.

Falls unser Admin nicht ohnehin schon komprimierte Verzeichnisse nutzt, ist das eine gute Idee.

Zitat von Dejan Vu:

Zitat von smallie:

Es gibt noch einen zweiten Aspekt: csv-Dateien harmonieren gut mit relationalen Datenbanktabellen. Mit direct load sind die Daten im Nu in der Datenbank

Genau, weil es ja nur ein Format gibt und einen Trenner...

Zitat:

Andersherum gesagt: traust die Leuten, die kein wohlgeformtes csv zu Wege bringen zu, daß sie gültige XMLs liefern?

Es gibt kein 'wohlgeformtes CSV'. Es gibt wohlgeformtes XML (was mir auch egal wäre) und es gibt validiertes XML (gegen ein Schema).

Naja, wir haben tatsächlich einen Lieferanten, bei dem immer nach einem Feiertag das Trennzeichen für einen Tag wechselt. Wir sind jedesmal auf's neue erstaunt.

Weiter gibt es einige Kandidaten, die es nicht schaffen, Quotes und Delimiter richtig zu escapen. Die sich sogar auf mehrmalige Nachfrage weigern, es richtig zu machen.

Im Großen und Ganzen aber gibt es keine Zweifel wie ein korrektes csv aussehen muß.

Zitat von Dejan Vu:

Wenn deine Zulieferer alle mitspielen und wissen, was sie tun, können sie auch proprietäres Binärformat schicken. Jetzt schicken sie ein proprietäres Text-Format, aber wenigstens spielen sie mit.

Ich wäre der erste, der in unserem Laden ein Veto gegen ein Binärformat einlegt - und sicher nicht der einzige. Von Menschen lesbare Dateien sind im Sinne von "machs einfach" nicht zu schlagen. Gerade heute hatte ich einen Fall, da wurden Geldbeträge mit sechs Nachkommastellen importiert. Ein kurzer Blick in die Datei reichte aus, um zu sehen, daß die Nachkommastellen tatsächlich so geliefert wurden und nicht vom Importer aufgrund eines aberwitzigen Fehlers hinzugemogelt wurden.

Solch ein Binärformat wäre die Hölle für mich, ebenso wie für den Support, wenn ein Kunde anruft und behauptet, die eine Buchung aus dem Jahr 2005 sei falsch.

Zitat von Dejan Vu:

PS: XML in einen Server geht genauso schnell und das Aufdröseln in Tabellen auch. Sind halt ein paar Zeilen mehr. Einmalig.

Ein paar Zeilen mehr? Ich persönlich schramme bei der Oracle-XML-Syntax immer an meine geistige Kapazitätsgrenze.

Und, naja, daß ein Aufdröseln eines XMLs in relationale Tabellen so schnell geht wie der Import bereits aufgedröselter csv-Dateien - das bezweifle ich. Denkst du, das Aufdröseln gibt es umsonst?

Zitat von Dejan Vu:

Aber jedem das Seine. CSV hat jedenfalls imho in der professionellen Softwareentwicklung und im Datenaustausch, der etwas auf sich hält, nichts verloren. Das ist nicht abwertend, sondern in meinem Umfeld so.

Wir sind fürchterlich off-topic. Deshalb sag' ich dazu mal nix.

[p80286]

Zitat von Dejan Vu:

Aber jedem das Seine. CSV hat jedenfalls imho in der professionellen Softwareentwicklung und im Datenaustausch, der etwas auf sich hält, nichts verloren. Das ist nicht abwertend, sondern in meinem Umfeld so.

Wenn Du eine nicht validierte XML-Datei bekommst, kannst Du Dich genauso auf die Nase legen, wie es mit einer CSV-Datei passieren kann. Schlimmer sind nur noch die Lieferanten, die grundsätzlich den Industriestandard EXCEL nutzen und sich dann wundern, daß bei 65.000 Zeilen Schluß ist, falls sie es überhaupt bemerken.

Gruß
K-H

[Dejan Vu]

Zitat von smallie:

Und, naja, daß ein Aufdröseln eines XMLs in relationale Tabellen so schnell geht wie der Import bereits aufgedröselter csv-Dateien - das bezweifle ich. Denkst du, das Aufdröseln gibt es umsonst?

Die Daten waren vorher (CSV) tabellarisch, dann werden sie es als XML wohl kaum nicht mehr sein. D.h. die Struktur ändert sich ja nicht, wohl aber das Format. Es geht aber imho nicht um die paar Sekunden beim Import (wenn Oracle hier zu umständlich ist, dann schreibt man ein XSLT, das die Daten umdröselt, und zwar in das Format, das das Bulk Insert von Oracle am besten beherrscht. Kann auch CSV sein )
Wichtig ist doch, das man mit externen Zulieferern belastbare Vereinbarungen trifft, die jeder einhalten kann, und die zudem mit frei verfügbaren Tools ('XML Validator') nachzuprüfen sind. Ich kann in meinen Vertrag ja auch schreiben, das eine Datei erst dann akzeptiert wird, wenn sie mit Hilfe der XSD auf www.xmlvalidator.com validiert werden kann.

Zitat von p80286:

Wenn Du eine nicht validierte XML-Datei bekommst, kannst Du Dich genauso auf die Nase legen, wie es mit einer CSV-Datei passieren kann. Schlimmer sind nur noch die Lieferanten, die grundsätzlich den Industriestandard EXCEL nutzen und sich dann wundern, daß bei 65.000 Zeilen Schluß ist, falls sie es überhaupt bemerken.

Vollkommen korrekt. Das Stichwort ist 'nicht validiert'. Wenn ich Daten bekommen soll, wird darüber eine schriftliche Vereinbarung getroffen. Bestandteil des Vertrages ist die XSD. Das kann man auch intern so regeln (es muss ja kein Vertrag sein, Kollegen erfüllen auch mündliche Vereinbarungen)

Das das intern nicht so einfach ist oder -noch schlimmer- bei Kunden gar nicht durchsetzbar ist, steht auf einem anderen Blatt. Aber wenn ich o.g. Prämisse nicht mit den eingehenden Rohdaten bekomme, dann schreibe ich mir einen Filter, der das exotische Fremdformat in mein einheitliches Import-Format übersetzt. Und das geht dann durch den Importer.

Die Krönung ist der Datenlieferant aus den o.g. Zulieferern, der seine Daten in Word als Tabelle formatiert, aber jedes mal von einem anderen Praktikanten und sich dann wundert, das man das nur abtippen kann und nicht elektronisch einlesen. Aber ein sich änderndes CSV-Format ist auch nicht schlecht. Wir sollten echt einen WTF-Thread aufmachen.