Array in csv schreiben

[smallie]

Zitat:

Zitat von Dejan Vu (Beitrag 1283678)

Speicherplatz? Zip das Zeugs.

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

Zitat:

Zitat von Dejan Vu (Beitrag 1283678)

Zitat:

Zitat von smallie (Beitrag 1283677)

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. :shock:

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:

Zitat von Dejan Vu (Beitrag 1283678)

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:

Zitat von Dejan Vu (Beitrag 1283678)

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. :cry:

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:

Zitat von Dejan Vu (Beitrag 1283678)

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:

Zitat von Dejan Vu (Beitrag 1283678)

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:

Zitat von smallie (Beitrag 1283689)

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:

Zitat von p80286 (Beitrag 1283695)

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.