CSV è una buona alternativa a XML e JSON? [chiuso]

CSV è considerato una buona opzione contro XML e JSON per i linguaggi di programmazione?

In genere utilizzo XML e JSON (o talvolta un file di testo semplice) come archivio di file flat. Tuttavia, recentemente mi sono imbattuto in un'implementazione CSV in PHP . In genere ho visto CSV utilizzato per input in file Excel , ma non l'ho mai usato con la programmazione. Sarebbe meglio di XML o JSON in qualche modo?

La risposta è, dipende.

CSV è ottimo per alcuni casi d'uso. Ad esempio come formato "streaming" per set di dati di grandi dimensioni, è più facile eseguire lo streaming rispetto a XML / JSON e i file CSV occupano molto meno spazio di archiviazione. Lo uso per lo streaming di set di dati nell'intervallo gigabyte in cui altri formati sono poco pratici.

È anche molto comune in alcuni settori quando si tratta di sistemi e flussi di lavoro legacy. Prova a importare JSON in MS Excel.

L'ODI ha recentemente commentato CSV, chiamando il 2014 "L'anno del CSV"

Per una formattazione CSV "corretta", considera l'utilizzo del tipo mime CSV nelle risposte HTTP.

Certamente no.

CSV è un formato tabella che si associa molto bene a set di dati o altri dati tabulari. Ma non tutti i dati sono tabulari! Più in generale, vogliamo serializzare i grafici degli oggetti . Questo può essere difficile nei seguenti casi:

• riferimenti circolari
• sottografi condivisi (ad esempio due oggetti che contengono entrambi lo stesso oggetto di un membro)
• oggetti di diverso tipo da serializzare nello stesso documento

Vogliamo inoltre essere in grado di deserializzare in modo affidabile gli oggetti dal nostro formato di archiviazione.

XML

È principalmente un linguaggio di markup estensibile . Può essere anche dotato di una scarpa da clacson per memorizzare anche strutture di dati generali. Il supporto linguistico per gli ID consente di creare grafici complessi, sebbene sia meglio utilizzato per gli alberi. È possibile verificare la correttezza di un documento rispetto a una specifica. Ci sono vari problemi con questo formato che possono renderlo poco pratico, come l'estrema verbosità.

JSON

È principalmente un modo per memorizzare semplici alberi di oggetti . Non esiste supporto per i grafici generali. JSON non ha alcun concetto di tipo oltre alle stringhe primitive , integer , float , boolean , null e l' array e l' oggetto dei tipi di raccolta .

YAML

Più facilmente comprensibile come estensione di JSON. Ha una nozione di alias che consente di creare grafici a oggetti di complessità arbitraria. Ha un concetto di metadati come tag che possono essere utilizzati per una corretta digitazione.

CSV

Non ha nulla, tranne una singola tabella. Se vogliamo archiviare i grafici degli oggetti, dovremmo usare uno schema simile

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

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

Esistono molti dialetti di CSV che non sono d'accordo su delimitatori, terminatori di riga, virgolette, caratteri di escape e molti altri problemi che lo rendono inadatto per dati generali (binari). Tutto ciò rende piuttosto difficile l'elaborazione dei dati CSV.

Quindi, in sostanza, le cose semplici sono difficili o impossibili con CSV quando lo si utilizza come formato di serializzazione generale.

Questa critica non si applica quando lo si utilizza per archiviare dati veramente tabulari come fogli presenze o una serie di misurazioni. Qui, CSV (spesso nella variante dei valori separati da tabulazione) è generalmente più compatto e più facile da usare rispetto agli altri formati di dati.

Devo anche dire che dipende da cosa stai cercando di ottenere. Per molti problemi non importa molto cosa scegli se il problema è abbastanza piccolo e la tua scelta si adatta bene al sistema esistente.

Prendere un sistema legacy e provare a calzare le scarpe in un nuovo formato a volte può essere un problema poiché hai introdotto più complessità e hai un nuovo sistema di input per il debug. L'ho visto molto quando nuove persone preferiscono qualcosa di diverso da ciò che esiste, o quando appare un nuovo formato e vogliono sperimentarlo. Questa potrebbe essere o non essere una buona idea, dipende dalle circostanze.

Anni fa ho lavorato su un sistema di database di grafici di ricerca che dipendeva da file CSV di vari formati. L'importatore di file CSV avrebbe creato grafici per noi e ha svolto molti anni di lavoro per eseguire il debug e ottimizzare il codice. Era veloce e flessibile e lo useremmo felicemente per avviare grandi progetti di ricerca. Quando XML è apparso sulla scena, abbiamo aggiunto un importatore XML, ma non è stato necessariamente un miglioramento in termini di velocità o espressione di complessità, e sicuramente XML non è stato migliore nell'esprimere strutture grafiche di CSV. JSON è molto più bello (e più intenso) di XML ma è simile per molti aspetti, quindi mi aspetto un risultato simile quando creo un nuovo importatore su quel sistema.

Ad un certo punto un cliente ha portato una grande quantità di dati nel formato "cobol" (come lo chiamavamo), file con linee di lunghezza variabile contenenti marcatori che indicavano come interpretare i byte che seguivano su quella linea. Veniva da un periodo in cui lo stoccaggio era costoso, quindi la compattezza era un requisito. Abbiamo importato quei dati convertendoli al volo in formato CSV e inserendoli nell'importatore CSV. È stato facile da fare e ha ridotto al minimo la quantità di debug e manutenzione, che sono cose positive. Se avessimo dovuto importare quel tipo di dati per tutto il tempo, avremmo potuto incorporarli direttamente nel sistema per ottenere guadagni in termini di prestazioni ed efficienza.

Quindi, dipende da cosa stai facendo e da cosa fa il sistema sottostante. Nel mio esempio, l'importatore CSV è stato progettato in modo solido e affidabile. Esiterei a dirti che un formato era migliore o peggiore senza capire cosa sta succedendo negli altri livelli che sto costruendo. Adoro JSON e lo preferisco, ma so che, date alcune strutture di dati complesse e set di dati abbastanza grandi, i file CSV possono funzionare anche molto bene.

No.

CSV non è in realtà un singolo formato. Esiste un'ampia varietà di stili di escape, separatori e altri problemi di formattazione che hanno molti file CSV in natura.

Se lo utilizzerai come archivio di file flat, l'utilizzo di JSON ti servirà molto meglio. JSON esegue la mappatura da e verso gli oggetti con molta meno seccatura di quella che dovrete fare con CSV.

Lo sconsiglio vivamente. Potrei essere OK per emettere CSV ad un certo punto (se l'utente lo richiede). Ma non è adatto per scopi di archiviazione / importazione. Ciò è dovuto principalmente al fatto che "CSV" è molto mal definito. La "C" indica "virgola" o "carattere" separati? Come trattate le stringhe di testo che contengono caratteri di escape come "? Ogni maledetta implementazione CSV tratta i caratteri di escape ecc. In modo diverso, il che porta a file che possono essere esportati ma non importati ecc.

Excel è una buona dimostrazione: nella versione inglese usa "," come separatore. In Germania, utilizza ";". Quindi una versione tedesca soffoca sui file CSV inglesi e viceversa ...

Il suo punto di forza è la leggibilità umana, che non dovrebbe essere scontata. Ma non farei affidamento su di esso come formato di archiviazione, è troppo fragile per quello scopo. Se devi esportare file per esseri umani, potresti usare CSV ma anche allora proverei ad usare una libreria che scrive in file xlsx (sono liberamente disponibili).

In generale NO. Perché? JSON e XML sono fondamentalmente lì per sbarazzarsi del temuto CSV. Sono gli approcci strutturati di ciò che è stato fatto non strutturato con CSV per lungo tempo. Sì, ci sono alcuni casi d'uso in cui CSV è ancora preferito, ma in generale in 9 casi su 10 è meglio non usare CSV.