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

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?

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.

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)

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.

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.

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.

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.

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.

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.

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

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

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

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.