Pourquoi continuons-nous à utiliser CSV? [fermé]


13

Pourquoi continuons-nous à utiliser CSV?

J'ai récemment décidé de travailler dans le domaine de la santé et malgré le merveilleux travail sur les normes de transfert de données, tous les transferts de données se font en CSV , à la fois pour les rapports à des organisations externes et pour les migrations de données lors de la mise en œuvre de nouveaux systèmes.

Malheureusement, l'utilisation de CSV est la cause de la répétition sans fin des mêmes erreurs stupides, avec la même perte de temps de développement. (mauvaise fuite, échec de la gestion des champs nuls, etc.)

Je sais que nous pouvons faire mieux, et tout entre JSON et XML (selon l'instance) irait bien. (La plupart du temps, il s'agit de données allant d'un serveur MS SQL 2005 à un autre!)

J'ai l'impression que chaque fois que je vois cela se produire, je regarde littéralement un développeur perdre du temps.

Alors pourquoi continuons-nous à nous élever les uns les autres? Quand allons-nous arrêter?


20
Si vous vous lancez dans le domaine de la santé et que vous pensez que le CSV est mauvais ... attendez jusqu'à ce que vous rencontriez HL7!
G__

3
@Greg LOL, ne lui faites pas peur, la surprise est toujours la meilleure :)
James Love

47
-1 Il s'agit d'une diatribe anti-CSV contre les problèmes non causés par CSV. Selon vous, que se passerait-il exactement si vous lisiez et écriviez du XML sans bibliothèque? Vos problèmes seraient cent fois pires.
Jesse Millikan

12
"Alors pourquoi continuons-nous à nous défoncer? Quand allons-nous nous arrêter?" Je ne sais pas, où je travaille, nous parvenons à bien utiliser CSV sans que personne ne soit traité (en effet - c'est l'étape XML qui est de loin plus frustrante). Peut-être que vous et vos collègues faites quelque chose de mal?
FrustratedWithFormsDesigner

3
Jusqu'à présent, toute la discussion passe à côté d'un problème très réel avec CSV: le caractère délimiteur est susceptible d'apparaître dans les données, et CSV adopte une approche moins qu'optimale à ce problème (mettre des guillemets autour des données pousse simplement le problème en aval) . Une meilleure approche serait d'utiliser des fichiers délimités par des tuyaux.
Larry Coleman

Réponses:


10

Dans votre cas, il semble que CSV ne soit pas un bon ajustement en raison de son manque de spécifications strictes.

Pour les données non triviales, ce n'est pas le bon choix.

Pourquoi / quand le CSV est-il un bon choix? Trop probablement d'instances à mentionner, les avantages de la simplicité pour les données plates sont évidents. Tant que les données sont correctement nettoyées / échappées, il n'y a aucun problème. D'une manière générale cependant, tous ces cas seraient simples / triviaux. Bien sûr, le délimiteur standard apparaissant dans le contenu est souvent pénible lorsqu'il s'agit de CSV.

Mais si vous faites quelque chose de plus complexe que de demander à un client non technique d'envoyer des données à partir d'une feuille Excel ou d'un autre cas d'utilisation similaire, le CSV est probablement insuffisant pour une utilisation sérieuse.

XML est un bien meilleur ajustement (oui encore plus que JSON) car vous pouvez faire des spécifications de schéma standardisées détaillées pour cela. (Sans oublier que les spécifications / schémas bénéficient de la flexibilité de plusieurs styles d'implémentation, XSD, DTD et Relax NG)

Pour les systèmes en boucle fermée, en particulier lorsque la bande passante est un problème, JSON peut être un meilleur ajustement que XML, mais le manque de langage (s) de spécification de schéma l'empêche souvent des applications de niveau entreprise.


3
En effet "Tant que les données sont correctement nettoyées / échappées". Cependant, de nombreux programmeurs semblent pouvoir se tromper en écrivant le leur (en pseudo-code write('"');write(fld1);write('"');ad nauseum). Ensuite, ils manquent de mettre des guillemets autour de quelque chose. Ensuite, ils écrivent leur propre analyseur ....
Gerry

3
Oui, l'équipe de roulage devrait vraiment commencer à utiliser ce truc sur Internet , peut-être même apprendre le sens du mot ... Bibliothèque.
ocodo

partage d'informations! code réutilisable! Idées stupides de nouvelle génération. Répéter les erreurs des autres était assez bon pour mon arrière grand-père de ^ 50 ans, et c'est assez bon pour moi!
Steve314

@ Steve314 - / me "fait face à la fois à l'horreur et à l'amusement."
ocodo

Mais CSV a une spécification difficile . Notre problème est maintenant celui habituel - Excel ne s'y conforme pas à 100%.
gbjbaanb

63

Permettez-moi de jeter quelques points en faveur de CSV:

  • CSV est simple (r que toute alternative suggérée dans OP) à implémenter et à analyser
  • Le CSV est compris par presque tous les logiciels de la planète (passés et présents)
  • CSV force un schéma simple et assez plat (il n'y a qu'une seule liste plate de champs)
  • CSV est plus lisible par l'homme que XML, JSON ou (UGH!) HL7 (V2.x, pré-xml)

14
Vous n'avez pas à jouer à «l'avocat du diable» ... tous ces arguments que vous faites sont parfaitement valables et expliquent pourquoi CSV est toujours utilisé. C'est tout simplement plus simple.
GrandmasterB

7
@Stephen: Combien de variantes différentes de CSV connaissez-vous?
FrustratedWithFormsDesigner

3
@FrustratedWithFormsDesigner à combien de conventions d'échappement pouvez-vous penser?
Stephen

3
@Pierre 303 J'aimerais que ce soit à l'abri des idiots. Je serais heureux si c'était à l'épreuve des développeurs.
Stephen

8
@ Pierre303, idiot proof ... Si vous pensez que vous avez «idiot proofed» quelque chose, vous ne l'avez pas testé avec suffisamment d'idiots.
ocodo

29

Rétrocompatibilité. Si le service Web de votre organisation externe gère le CSV et que tous vos outils existants gèrent le CSV, aucune des parties n'a la moindre motivation pour passer à un nouveau service. Pourquoi votre organisation externe prendrait-elle en charge un format différent? Personne avec qui ils travaillent ne peut l'utiliser! Pourquoi voudriez-vous commencer à produire un format différent? Aucune des organisations avec lesquelles vous travaillez ne l'accepte!

Le vrai problème que je vois ici est, pourquoi vos développeurs roulent-ils leur propre code CSV à chaque fois? S'ils utilisaient une bibliothèque CSV stable et solide, ils n'auraient pas les problèmes que vous décrivez. Les problèmes sont causés par les développeurs qui déploient leur propre solution au lieu d'utiliser une bibliothèque, et honnêtement, je ne vois pas comment le passage à JSON ou XML résout comme par magie cela. Vous auriez toujours des gens qui essaient de les regex au lieu d'utiliser une bibliothèque.


4
+1 pour rouler chaque fois. Je vois des développeurs qui n'apprennent pas, pas un format de données imparfait. :-)
G__

«rétrocompatibilité» - vous avez bien sûr raison - mais ne pas aller de l'avant coûte des milliers.
Stephen

C'est bien de rouler votre propre bibliothèque CSV ... il suffit de la réutiliser !
GrandmasterB

5
@Stephen: Non, réimplémenter CSV chaque fois que vous en avez besoin coûte des milliers. Le format CSV est très bien, les développeurs qui ne peuvent pas le faire correctement sont le problème.
Anon.

6
@Stephen: Votre problème avec CSV est donc qu'il est trop simple et que vous voulez quelque chose de plus complexe?
Anon.

15

CSV est un peu plus rapide , de plus petite taille , très facile à manipuler (même dans Excel) et de nombreuses applications existantes le comprennent, c'est une norme largement utilisée .

C'est toujours un premier choix dans de nombreuses situations.

Personnellement, j'aime toujours beaucoup ce format. Mais j'utilise aussi JSON, mais pour d'autres applications comme l'interface utilisateur Web.


1
Je suis d'accord avec chaque bit de cela, sauf l'utilisation initiale de "un peu".
Orbling le

3
Cela peut être un bas *** absolu avec Excel si vous avez des données qui doivent conserver les zéros en tête .... demandez-moi comment je sais! ... à part cela, Excel fournit une bonne interface.
Dal

@Dal: Avant, je travaillais dans une caisse populaire et je devais gérer des fichiers CSV contenant des numéros de carte de crédit. Qui ont 16 chiffres. Cet Excel arrondi à 15.
dan04

Ou pire qu'il les a convertis en notation scientifique. :( Je me souviens de la première fois que j'ai eu une erreur sur notre traitement ACH qu'un numéro de compte distant n'était pas valide, seulement pour découvrir que quelqu'un avait édité le csv dans Excel (seulement pour supprimer une ligne) et qu'il avait changé un tas de 30 chiffres des comptes en 2.3456356e29 et autres
cabbey

1
@Jeanne: Si CSV avait effectivement une distinction nombre / chaîne comme JSON, il serait assez facile de dire à Excel de quel type sont les valeurs. Ces problèmes sont dus en grande partie au type CSV.
dan04

15

D'abord et avant tout, car même si la consommation de données CSV peut être (légèrement) non triviale, sa génération est extrêmement facile.

Je voudrais également souligner que ni JSON ni XML n'est vraiment plus facile à obtenir correctement (pour le producteur ou le consommateur). En fait, il suffit à peine de regarder autour de soi pour savoir que beaucoup de gens essaient d'utiliser des expressions rationnelles pour analyser les données XML, même s'il ne fait aucun doute que cela ne peut pas et ne fonctionnera pas.

La plupart des problèmes qui peuvent (et surviennent) avec CSV peuvent (et surviennent) également avec JSON et XML. XML, en particulier, ajoute de nombreux autres problèmes potentiels. Une bibliothèque pour analyser les données XML est généralement plus grande, plus lente et plus difficile à utiliser qu'une bibliothèque similaire pour les données CSV.


1
sembler le produire correctement est extrêmement facile, consommer quelque chose qui n'a pas de spécification n'est pas trivial lorsque vous avez des données non triviales.
Stephen

2
@Stephen: notez que je n'ai pas inclus "correctement" dans cette première phrase. Son omission était intentionnelle!
Jerry Coffin

4

Tout d'abord, je conviens qu'il y a des problèmes très réels avec le format:

  • Il est strictement tapé.
    • Sans distinction entre le texte et les valeurs numériques, Excel devinera mal et foirera vos codes postaux et numéros de carte de crédit.
    • Il n'existe aucun moyen standard de représenter les données binaires.
    • Il n'existe aucun moyen standard de distinguer entre NULLet '', ce qui est un problème lors de l'importation de fichiers CSV dans des bases de données SQL.
  • Mauvaise prise en charge des "caractères spéciaux".
    • L'absence de références de caractères numériques comme (XML &#xNNNN;ou JSON\uNNNN ) signifie qu'il n'existe aucun moyen standard de représenter les caractères de contrôle ou les caractères non ASCII.
    • De nombreuses implémentations n'implémentent pas correctement les sauts de ligne dans un champ.
  • L'absence d'un standard. Il y a la RFC 4180 , mais elle n'est pas universellement suivie.

Mais d'autre part:

  • Les alternatives sont pires. Le JSON et le XML, conçus autour d'arbres, sont mal adaptés aux données basées sur des tables, en particulier en termes de ...
  • COMPACITÉ! En XML, vous devez avoir une balise de début et une balise de fin pour chaque colonne de chaque ligne. Dans CSV, vous n'écrivez les en-têtes de colonne qu'une seule fois.
  • CSV est très facile à générer.
  • Les non-programmeurs peuvent ouvrir des fichiers CSV dans Excel.

en marche arrière; l'utilisation de ces données dans Excel serait une infraction licenciable, le CSV est facile à générer mal, la compacité n'est pas un problème, les arbres sont mieux adaptés à ces données.
Stephen

4

Parce que beaucoup d'analystes utilisent Excel (pour les tableaux croisés dynamiques et autres), et il est beaucoup plus facile de générer du CSV que de générer du format Excel natif.

Note de bas de page: étant donné le nombre de problèmes que j'ai vus avec Excel dans la gestion des fichiers CSV, comme la suppression des zéros non significatifs et la perte de précision, c'est probablement un faux sentiment d'être plus facile.


Ce +1000. Excel est l'application qui tue (une fois que vous la connaissez) pour une analyse rapide et sale des données. La possibilité d'exporter vers Excel donne de puissants pouvoirs aux non-développeurs dans les domaines des affaires, de la recherche, etc. Excel gère le monde. Les exportations CSV exécutent Excel.
johannes

2

S'il y a une chose qui ne va pas avec CSV, c'est que CSV semble si simple que de nombreux développeurs essaient d'inventer leurs propres analyseurs / rédacteurs et plus tard blâment CSV de ne pas gérer correctement les fuites. Avec un bon analyseur CSV (beaucoup de bons là-bas), il n'y aura aucun problème du tout.

Quelqu'un a mentionné que CSV n'est pas bon pour les données non triviales, mais je ne suis pas d'accord. XML autorise les données non triviales car différents ensembles de données peuvent être placés dans différentes balises "conteneur". Avec CSV, vous pouvez toujours mettre différentes données dans différents fichiers pour obtenir le même effet.

De plus, à mon avis, l'utilisation de XML pour le transfert de données va fondamentalement à l'encontre du but de XML - le transfert de données implique généralement un contrat stable entre les fournisseurs et les consommateurs tandis que XML est destiné à transporter des informations extensibles sujettes à interprétation lors de leur consommation.


1

Je suppose que CSV est juste bon lorsque vous n'avez que des données texte simples, avec seulement des virgules et soit un point-virgule / fin à la fin.

Les données arborescentes ou composites peuvent difficilement être utilisées avec CSV.

CSV n'est qu'un simple tableau 2D de texte comme dans Excel, rien de bien ...


1

Il s'agit vraiment de mainframes et d'exceller ici.

Mainframes parce que ces anciens systèmes ont compris comment communiquer en utilisant CSV. Ainsi, les grandes applications qui exportent les données peuvent les lire et les écrire et n'ont aucune raison de changer maintenant.

Excel car il peut ouvrir directement des CSV. En fait, il prend en charge l'extension .csv lorsque vous l'installez. Les utilisateurs cliquent simplement sur l'icône Excel légèrement drôle et elle s'ouvre et crée une belle grille avec laquelle ils peuvent se débattre.

Maintenant, les versions modernes d'Excel sont tout à fait capables de lire, disons, XML, directement. Mais pour ce faire, un utilisateur doit comprendre un peu plus que "double-cliquer sur cette image". Et double-cliquer sur la bonne image peut être trop demander dans certaines industries. . .


-1

J'ai vu beaucoup de réponses techniques, mais je soupçonne que la raison pour laquelle les gens utilisent CSV est la même raison pour laquelle ils utilisent beaucoup d'autres techniques / technologies: parce que c'est celle qu'ils connaissent le mieux


-1

pourquoi dois-je l'utiliser?

  1. le client le veut
  2. il est plus rapide que xml sur le réseau (charge réseau plus petite)
  3. rien de plus complexe n'est nécessaire pour transmettre les données
  4. plateforme croisée
  5. lisible par l'homme
  6. facile à implémenter des lecteurs et des écrivains pour cela

etc.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.