it-swarm.com.de

Ist CSV eine gute Alternative zu XML und JSON?

Ist CSV eine gute Option gegen XML und JSON für Programmiersprachen?

Ich verwende im Allgemeinen XML und JSON (oder manchmal eine einfache Textdatei) als Flatfile-Speicher. Kürzlich bin ich jedoch auf eine CSV-Implementierung in PHP gestoßen. Ich habe im Allgemeinen gesehen, dass CSV für Eingaben in Excel -Dateien verwendet wird, aber ich habe es nie für die Programmierung verwendet. Wäre es in irgendeiner Weise besser als XML oder JSON?

21
Vishwas G

Die Antwort ist, es kommt darauf an.

CSV eignet sich hervorragend für bestimmte Anwendungsfälle. Als "Streaming" -Format für große Datenmengen ist es beispielsweise einfacher zu streamen als XML/JSON, und CSV-Dateien benötigen viel weniger Speicherplatz. Ich verwende es, um Datensätze im Gigabyte-Bereich zu streamen, wo andere Formate unpraktisch sind.

Es ist auch wirklich in bestimmten Branchen üblich, wenn es um Legacy-Systeme und Workflows geht. Versuchen Sie, JSON in MS Excel zu importieren.

Der ODI äußerte sich kürzlich zu CSV und nannte 2014 "Das Jahr der CSV"

Verwenden Sie für eine "korrekte" CSV-Formatierung in Ihren HTTP-Antworten CSV-MIME-Typ .

41
tom

Mit Sicherheit nicht.

CSV ist ein Tabellenformat, das sehr gut Datensätzen oder anderen tabellarischen Daten zugeordnet werden kann. Aber nicht alle Daten sind tabellarisch! Im Allgemeinen möchten wir Objektgraphen serialisieren. Dies kann in folgenden Fällen schwierig sein:

  • zirkelverweise
  • gemeinsam genutzte Untergraphen (z. B. zwei Objekte, die beide dasselbe Objekt wie ein Mitglied enthalten)
  • objekte unterschiedlichen Typs, die in dasselbe Dokument serialisiert werden sollen

Wir möchten weiterhin in der Lage sein, die Objekte zuverlässig aus unserem Speicherformat zu de-serialisieren.

XML

Ist in erster Linie eine erweiterbare Markup Sprache. Es kann mit Schuhen versehen werden, um auch allgemeine Datenstrukturen zu speichern. Sprachunterstützung für IDs bedeutet, dass komplexe Diagramme erstellt werden können, obwohl dies am besten für Bäume verwendet wird. Ein Dokument kann anhand einer Spezifikation auf Richtigkeit geprüft werden. Es gibt verschiedene Probleme mit diesem Format, die es unpraktisch machen können, wie zum Beispiel die extreme Ausführlichkeit.

JSON

Ist in erster Linie eine Möglichkeit, einfache Objekte zu speichern Bäume. Allgemeine Grafiken werden nicht unterstützt. JSON hat kein Konzept von Typ jenseits der Grundelemente Zeichenfolge, Ganzzahl, Float, Boolescher Wert , null und die Auflistungstypen Array und Objekt.

YAML

Am einfachsten als Erweiterung von JSON zu verstehen. Hat den Begriff Aliase, mit dem Objektgraphen beliebiger Komplexität erstellt werden können. Hat ein Konzept von Metadaten wie Tags, das für die richtige Eingabe verwendet werden kann.

CSV

Hat nichts außer einem einzigen Tisch. Wenn wir Objektgraphen speichern möchten, müssten wir ein Schema wie verwenden

#ID,Type,Field1,Field2,...,FieldN

1,String,foo
2,String,bar
3,Array<String>,1,2

Es gibt viele Dialekte von CSV, die in Bezug auf Trennzeichen, Zeilenabschlusszeichen, Anführungszeichen, Escapezeichen und viele andere Probleme, die es für allgemeine (binäre) Daten ungeeignet machen, nicht übereinstimmen. All dies macht es ziemlich schwierig, CSV-Daten zu verarbeiten.

Grundsätzlich sind einfache Dinge mit CSV schwierig oder unmöglich, wenn es als allgemeines Serialisierungsformat verwendet wird.

Diese Kritik gilt nicht, wenn damit wirklich tabellarische Daten wie Arbeitszeitnachweise oder eine Reihe von Messungen gespeichert werden. Hier ist CSV (häufig in der Variante der durch Tabulatoren getrennten Werte) normalerweise kompakter und einfacher zu verwenden als die anderen Datenformate.

22
amon

Ich muss auch sagen, dass es davon abhängt, was Sie erreichen wollen. Bei vielen Problemen spielt es keine Rolle, was Sie auswählen, wenn das Problem klein genug ist und Ihre Auswahl gut zum vorhandenen System passt.

Es kann manchmal problematisch sein, ein Legacy-System zu verwenden und zu versuchen, in einem neuen Format zu arbeiten, da Sie mehr Komplexität eingeführt haben und ein neues Eingabesystem zum Debuggen haben. Ich habe dies oft gesehen, wenn neue Leute etwas anderes bevorzugen als das, was existiert, oder wenn ein neues Format erscheint und sie damit experimentieren möchten. Dies kann eine gute Idee sein oder auch nicht, es hängt von den Umständen ab.

Vor Jahren arbeitete ich an einem Datenbanksystem für Forschungsgraphen, das von CSV-Dateien in verschiedenen Formaten abhing. Der CSV-Dateiimporter hat Diagramme für uns erstellt und viele Jahre gearbeitet, um den Code zu debuggen und zu optimieren. Es war sowohl schnell als auch flexibel und wir würden es gerne für bootstrap große Forschungsprojekte verwenden. Als XML in der Szene erschien, haben wir einen XML-Importer hinzugefügt, aber dies war nicht unbedingt eine Verbesserung der Geschwindigkeit oder des Ausdrucks von Komplexität, und XML war sicherlich nicht besser darin, Diagrammstrukturen auszudrücken als CSV. JSON ist viel netter (und knapper) als XML, aber in vielerlei Hinsicht ähnlich. Daher würde ich ein ähnliches Ergebnis erwarten, wenn Sie einen neuen Importer auf diesem System erstellen.

Zu einem bestimmten Zeitpunkt ließ ein Kunde eine große Datenmenge im "Cobol" -Format (wie wir es nannten) einbringen. Dateien mit Zeilen variabler Länge enthielten Markierungen, die angaben, wie die auf diese Zeile folgenden Bytes zu interpretieren sind. Es kam aus einer Zeit, als die Lagerung teuer war, so dass Kompaktheit eine Voraussetzung war. Wir haben diese Daten importiert, indem wir sie im laufenden Betrieb in das CSV-Format konvertiert und dem CSV-Importer zugeführt haben. Das war einfach und minimierte den Aufwand für Debugging und Wartung, was gut ist. Wenn wir diese Art von Daten die ganze Zeit importieren müssten, hätten wir sie möglicherweise direkt in das System eingebaut, um Leistungs- und Effizienzgewinne zu erzielen.

Es hängt also davon ab, was Sie tun und was das zugrunde liegende System tut. In meinem Beispiel war der CSV-Importeur solide konstruiert und zuverlässig. Ich würde zögern, Ihnen zu sagen, dass ein Format besser oder schlechter war, ohne zu verstehen, was in den anderen Ebenen, die ich baue, vor sich geht. Ich liebe JSON und bevorzuge es, aber ich weiß, dass CSV-Dateien angesichts bestimmter komplexer Datenstrukturen und ausreichend großer Datenmengen auch sehr gut funktionieren können.

4
Fran K.

Nein.

CSV ist nicht wirklich ein einzelnes Format. Es gibt eine Vielzahl von Stilen für Escape-, Trenn- und andere Formatierungsprobleme, die viele CSV-Dateien in freier Wildbahn haben.

Wenn Sie dies als Flatfile-Speicher verwenden, ist die Verwendung von JSON für Sie viel besser geeignet. JSON ordnet Objekte mit viel weniger Aufwand zu und von Objekten zu, als Sie mit CSV zu tun haben.

3
whatsisname

Ich würde dringend davon abraten. Möglicherweise kann ich CSV irgendwann ausgeben (wenn der Benutzer dies wünscht). Für Speicher-/Importzwecke ist es jedoch nicht geeignet. Dies ist hauptsächlich auf die Tatsache zurückzuführen, dass "CSV" sehr schlecht definiert ist. Zeigt das "C" "Komma" oder "Zeichen" getrennt an? Wie behandeln Sie Textzeichenfolgen, die Escape-Zeichen enthalten, wie "? Jede verdammte CSV-Implementierung behandelt Escape-Zeichen usw. unterschiedlich, was zu Dateien führt, die ex-, aber nicht importiert werden können usw.

Excel ist eine gute Demonstration: In der englischen Version wird "," als Trennzeichen verwendet. In Deutschland wird ";" verwendet. Eine deutsche Version verschluckt sich also an englischen CSV-Dateien und umgekehrt ...

Die Hauptstärke liegt in der Lesbarkeit des Menschen, die nicht außer Acht gelassen werden sollte. Aber ich würde mich nicht darauf als Speicherformat verlassen, es ist zu spröde für diesen Zweck. Wenn Sie Dateien für Menschen exportieren müssen, können Sie CSV verwenden, aber selbst dann würde ich versuchen, eine Bibliothek zu verwenden, die in xlsx-Dateien schreibt (diese sind frei verfügbar).

0
Christian Sauer