Perché continuiamo a utilizzare CSV? [chiuso]

Perché continuiamo a utilizzare CSV?

Di recente sono passato al lavoro nel campo della salute e, nonostante il meraviglioso lavoro sugli standard di trasferimento dei dati, tutto il trasferimento dei dati è in CSV , sia per la segnalazione a organizzazioni esterne, sia per le migrazioni dei dati durante l'implementazione di nuovi sistemi.

Sfortunatamente l'uso di CSV è la causa della ripetizione senza fine degli stessi stupidi errori, con la stessa perdita di tempo degli sviluppatori. (cattivo escape, impossibile gestire i campi null ecc.)

So che possiamo fare di meglio, e qualsiasi cosa tra JSON e XML (a seconda dell'istanza) andrebbe bene. (Il più delle volte si tratta di dati che vanno da un MS SQL Server 2005 ad un altro!)

Sento che ogni volta che vedo questo accada sto letteralmente guardando uno sviluppatore perdere tempo.

Quindi, perché continuiamo a tormentarci a vicenda? Quando ci fermeremo?

Nel tuo caso, sembra che CSV non sia adatto a causa della mancanza di specifiche rigide.

Per dati non banali non è la scelta giusta.

Perché / quando CSV è una buona scelta? Probabilmente troppi casi da menzionare, i vantaggi della semplicità per i dati flat sono evidenti. Finché i dati vengono disinfettati / sfuggiti correttamente, non ci sono problemi. In generale, però, tutti questi casi sarebbero semplici / banali. Naturalmente, il delimitatore standard che appare nel contenuto è spesso una seccatura quando si ha a che fare con CSV.

Ma se stai facendo qualcosa di più coinvolto che ottenere un client non tecnico per inviare dati da un foglio Excel o da un altro caso d'uso simile, CSV è probabilmente insufficiente per qualsiasi uso serio.

XML è molto più adatto (sì, anche più di JSON) poiché è in grado di eseguire specifiche dello schema standardizzate dettagliate per esso. (Per non parlare del fatto che le specifiche / schemi godono della flessibilità di più stili di implementazione, XSD, DTD e Relax NG)

Per i sistemi a circuito chiuso, in particolare quando la larghezza di banda è una preoccupazione, JSON può adattarsi meglio di XML, ma la mancanza di linguaggi di specifica dello schema spesso lo preclude dalle applicazioni a livello aziendale.

Vorrei eliminare alcuni punti a favore di CSV:

• CSV è semplice (r rispetto a qualsiasi alternativa suggerita in OP) da implementare e analizzare
• CSV è compreso da quasi tutti i software sul pianeta (passato e presente)
• CSV impone uno schema abbastanza piatto e semplice (esiste un unico elenco piatto di campi)
• CSV è più leggibile dall'uomo rispetto a XML, JSON o (UGH!) HL7 (V2.x, pre-xml)

Compatibilità con le versioni precedenti. Se il servizio Web delle organizzazioni esterne gestisce CSV e tutti gli strumenti esistenti gestiscono CSV, nessuna delle parti ha alcuna motivazione per passare a un nuovo servizio. Perché la tua organizzazione esterna dovrebbe iniziare a supportare un formato diverso? Nessuno con cui lavorano possono usarlo! Perché dovresti iniziare a produrre un formato diverso? Nessuna delle organizzazioni con cui lavori lo accetta!

Il vero problema che vedo qui è, perché i tuoi sviluppatori inseriscono il proprio codice CSV ogni volta? Se usassero una libreria CSV stabile e solida, non avrebbero i problemi che descrivi. I problemi sono causati dagli sviluppatori che implementano la propria soluzione invece di utilizzare una libreria, e onestamente non vedo come il passaggio a JSON o XML lo risolva magicamente. Avresti ancora persone che provano a riproporle invece di usare una libreria.

CSV è un po ' più veloce , di dimensioni più ridotte , molto facile da gestire (anche in Excel) e molte applicazioni esistenti lo capiscono, è uno standard ampiamente utilizzato .

È ancora una prima scelta in molte situazioni.

Personalmente mi piace ancora molto quel formato. Ma uso anche JSON, ma per altre applicazioni come l'interfaccia utente Web.

Innanzitutto, perché anche se il consumo dei dati CSV può essere (leggermente) non banale, generarli è estremamente semplice.

Vorrei anche sottolineare che né JSON né XML sono davvero più facili da ottenere (sia per il produttore che per il consumatore). In effetti, si deve a malapena guardarsi intorno per sapere che molte persone cercano di usare regex per analizzare i dati XML, anche se non c'è assolutamente dubbio che farlo non possa e non funzionerà.

La maggior parte dei problemi che possono (e fare) insorgere con CSV possono (e fare) insorgere anche con JSON e XML. XML, in particolare, aggiunge molti altri potenziali problemi propri. Una libreria per analizzare i dati XML è generalmente più grande, più lenta e più difficile da usare rispetto a una libreria simile per i dati CSV.

Innanzitutto, sono d'accordo che ci sono alcuni problemi molto reali con il formato:

• È tipizzato in modo rigoroso.
  • Senza alcuna distinzione tra testo e valori numerici, Excel indovinerà errato e rovinerà i tuoi codici postali e numeri di carta di credito.
  • Non esiste un modo standard per rappresentare i dati binari.
  • Non esiste un modo standard per distinguere tra NULLe '', il che è un problema durante l'importazione di file CSV in database SQL.
• Scarso supporto per "personaggi speciali".
  • La mancanza di riferimenti a caratteri numerici come (XML &#xNNNN;o JSON \uNNNN) significa che non esiste un modo standard per rappresentare caratteri di controllo o caratteri non ASCII.
  • Molte implementazioni non implementano correttamente le interruzioni di riga all'interno di un campo.
• La mancanza di uno standard. C'è RFC 4180 , ma non è universalmente seguito.

Ma d'altra parte:

• Le alternative sono peggiori. JSON e XML, essendo progettati attorno agli alberi, non sono adatti ai dati basati su tabella, in particolare in termini di ...
• COMPATTEZZA! In XML, devi avere un tag iniziale e un tag finale per ogni colonna in ogni riga. In CSV, scrivi le intestazioni di colonna solo una volta.
• CSV è molto facile da generare.
• I non programmatori possono aprire i file CSV in Excel.

Poiché molti analisti utilizzano Excel (per le tabelle pivot e simili), è molto più semplice generare CSV che produrre formato Excel nativo.

Nota: dato quanti problemi ho riscontrato con Excel nella gestione dei file CSV, come la rimozione di zero iniziali e la perdita di precisione, questo è probabilmente un falso senso di essere più facile.

Se c'è una cosa che non va in CSV, è che CSV sembra così semplice che molti sviluppatori cercano di inventare i propri parser / scrittori e in seguito danno la colpa a CSV per non aver gestito correttamente l'escaping. Con un buon parser CSV (molti buoni là fuori), non ci sarà alcun problema.

Qualcuno ha citato CSV non è buono per i dati non banali ma non sono d'accordo. XML consente dati non banali perché diversi set di dati possono essere inseriti in diversi tag "container". Con CSV, puoi sempre inserire dati diversi in file diversi per ottenere lo stesso effetto.

Inoltre, a mio avviso, l'utilizzo dell'XML per il trasferimento dei dati è fondamentalmente contrario allo scopo dell'XML: il trasferimento dei dati di solito implica un contratto stabile tra fornitori e consumatori, mentre l'XML ha lo scopo di trasportare informazioni espandibili soggette a interpretazione quando vengono consumate.

Immagino che i CSV siano buoni solo quando hai solo dati di testo semplici, con solo virgole e punto e virgola / fine alla fine.

I dati architetturali dell'albero o i dati composti non possono essere usati con CSV.

CSV è solo una semplice matrice 2D di testo come in Excel, niente di più ...

Si tratta davvero di mainframe ed eccellere qui.

Mainframe perché quei vecchi sistemi hanno capito come comunicare usando CSV. Quindi le grandi app che scaricano i dati possono leggerle e scriverle e non hanno motivo di cambiare ora.

Excel perché può aprire direttamente CSV. In effetti, assume l'estensione .csv quando lo si installa. Gli utenti fanno semplicemente clic sull'icona excel dall'aspetto leggermente divertente e si apre e crea una bella griglia con cui possono litigare.

Ora, le versioni moderne di Excel sono abbastanza capaci di leggere, diciamo, XML, direttamente. Ma per fare ciò, un utente deve capire un po 'di più che "fare doppio clic su quell'immagine". E fare doppio clic sull'immagine giusta può essere troppo da chiedere in alcuni settori. . .

Ho visto molte risposte tecniche ma sospetto che il motivo per cui le persone usano il CSV sia lo stesso motivo per cui le persone usano molte altre tecniche / tecnologie: perché è quella con cui hanno più familiarità

perché lo uso?

1. il cliente lo vuole
2. è più veloce di xml sulla rete (carico di rete ridotto)
3. non è necessario nulla di più complesso per trasmettere i dati
4. piattaforma incrociata
5. leggibile dagli umani
6. facile da implementare lettori e scrittori per questo

ecc ecc.