CSV est-il une bonne alternative à XML et JSON? [fermé]

CSV est-il considéré comme une bonne option contre XML et JSON pour les langages de programmation?

J'utilise généralement XML et JSON (ou parfois un fichier texte brut) comme stockage de fichier plat. Cependant, récemment, je suis tombé sur une implémentation CSV en PHP . J'ai généralement vu CSV utilisé pour les entrées dans les fichiers Excel , mais je ne l'ai jamais utilisé avec la programmation. Serait-ce mieux que XML ou JSON?

La réponse est, cela dépend.

CSV est idéal pour certains cas d'utilisation. Par exemple, en tant que format de «streaming» pour les grands ensembles de données, il est plus facile de diffuser que XML / JSON, et les fichiers CSV prennent beaucoup moins d'espace de stockage. Je l'utilise pour diffuser des jeux de données dans la plage de gigaoctets où d'autres formats ne sont pas pratiques.

Il est également très courant dans certaines industries lorsqu'il s'agit de systèmes et de flux de travail hérités. Essayez d'importer JSON dans MS Excel.

L'ODI a récemment commenté le CSV, appelant 2014 «l'année du CSV»

Pour un formatage CSV "correct", envisagez d'utiliser le type MIME CSV dans vos réponses HTTP.

Certainement pas.

CSV est un format de tableau qui correspond très bien aux ensembles de données ou à d'autres données tabulaires. Mais toutes les données ne sont pas tabulaires! Plus généralement, nous voulons sérialiser les graphes d'objets . Cela peut être difficile dans les cas suivants:

• références circulaires
• sous-graphiques partagés (par exemple, deux objets qui contiennent tous deux le même objet qu'un membre)
• objets de différents types à sérialiser dans le même document

Nous voulons en outre pouvoir désérialiser de manière fiable les objets de notre format de stockage.

XML

Est principalement un langage de balisage extensible . Il peut également être conçu pour stocker des structures de données générales. La prise en charge linguistique des ID signifie que des graphiques complexes peuvent être créés, bien qu'il soit préférable de les utiliser pour les arbres. L'exactitude d'un document peut être testée par rapport à une spécification. Il existe divers problèmes avec ce format qui peuvent le rendre impraticable, tels que l'extrême verbosité.

JSON

Est principalement un moyen de stocker des arbres d' objets simples . Il n'y a pas de support pour les graphiques généraux. JSON n'a aucun concept de type au-delà de la chaîne primitive , de l' entier , du flottant , du booléen , du null et du tableau des types de collection et de l' objet .

YAML

Le plus facilement compris comme une extension de JSON. Possède une notion d' alias qui permet de créer des graphes d'objets de complexité arbitraire. A un concept de métadonnées comme des balises qui peuvent être utilisées pour une saisie correcte.

CSV

N'a rien, sauf une seule table. Si nous voulons stocker des graphiques d'objets, nous devons utiliser un schéma comme

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

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

Il existe de nombreux dialectes de CSV en désaccord sur les délimiteurs, les terminateurs de ligne, les guillemets, les caractères d'échappement et de nombreux autres problèmes qui le rendent inapproprié pour les données générales (binaires). Tout cela rend le traitement des données CSV assez difficile.

Donc, fondamentalement, les choses faciles sont difficiles ou impossibles avec CSV lorsque vous l'utilisez comme format de sérialisation général.

Cette critique ne s'applique pas lors de son utilisation pour stocker des données véritablement tabulaires comme des feuilles de temps ou une série de mesures. Ici, CSV (souvent dans la variante des valeurs séparées par des tabulations) est généralement plus compact et plus facile à utiliser que les autres formats de données.

Je dois également dire que cela dépend de ce que vous essayez de réaliser. Pour de nombreux problèmes, peu importe ce que vous choisissez si le problème est assez petit et si votre choix correspond bien au système existant.

Prendre un système hérité et essayer de chausse-pied dans un nouveau format peut parfois être un problème car vous avez introduit plus de complexité et avez un nouveau système d'entrée à déboguer. Je l'ai souvent vu lorsque de nouvelles personnes préfèrent quelque chose de différent de ce qui existe, ou lorsqu'un nouveau format apparaît et qu'elles veulent l'expérimenter. Cela peut ou non être une bonne idée, cela dépend des circonstances.

Il y a des années, j'ai travaillé sur un système de base de données de graphiques de recherche qui dépendait de fichiers CSV de différents formats. L'importateur de fichiers CSV construirait des graphiques pour nous et il aurait fallu de nombreuses années de travail pour déboguer et optimiser le code. Il était à la fois rapide et flexible et nous l'utiliserions avec plaisir pour démarrer de grands projets de recherche. Lorsque XML est apparu sur la scène, nous avons ajouté un importateur XML, mais ce n'était pas nécessairement une amélioration en termes de vitesse ou d'expression de la complexité, et certainement XML n'était pas meilleur pour exprimer les structures de graphe que CSV. JSON est beaucoup plus agréable (et plus subtil) que XML mais est similaire à bien des égards, je m'attends donc à un résultat similaire lors de la création d'un nouvel importateur sur ce système.

À un moment donné, un client a importé une énorme quantité de données au format (comme nous l'avons appelé) "cobol", des fichiers avec des lignes de longueur variable contenant des marqueurs qui indiquaient comment interpréter les octets qui suivaient sur cette ligne. Cela venait d'une époque où le stockage était coûteux, donc la compacité était une exigence. Nous avons importé ces données en les convertissant au format CSV à la volée et en les introduisant dans l'importateur CSV. Cela a été facile à faire et a minimisé la quantité de débogage et de maintenance, ce qui est une bonne chose. Si nous devions importer ce type de données tout le temps, nous aurions pu les intégrer directement dans le système pour obtenir des gains de performances et d'efficacité.

Cela dépend donc de ce que vous faites et de ce que fait le système sous-jacent. Dans mon exemple, l'importateur CSV était solidement conçu et fiable. J'hésiterais à vous dire qu'un format était meilleur ou pire sans comprendre ce qui se passe dans les autres couches que je construis. J'adore JSON et je le préfère, mais je sais qu'étant donné certaines structures de données complexes et des ensembles de données suffisamment grands, les fichiers CSV peuvent également fonctionner très bien.

Non.

CSV n'est pas vraiment un format unique. Il existe une grande variété de styles pour les échappements, les séparateurs et d'autres problèmes de formatage que de nombreux fichiers CSV dans la nature ont.

Si vous comptez l'utiliser comme stockage de fichiers à plat, l'utilisation de JSON vous sera beaucoup plus utile. JSON mappe vers et depuis des objets avec beaucoup moins de tracas que vous n'aurez à vous contenter de CSV pour le faire.

Je le déconseille fortement. Je pourrais être d'accord pour sortir CSV à un moment donné (si l'utilisateur le demande). Mais c'est un mauvais ajustement à des fins de stockage / importation. Cela est principalement dû au fait que "CSV" est très mal défini. Le «C» indique-t-il «virgule» ou «caractère» séparé? Comment traitez-vous les chaînes de texte qui contiennent des caractères d'échappement comme "? Chaque implémentation CSV maudite traite différemment les caractères d'échappement etc., ce qui conduit à des fichiers qui peuvent être ex, mais pas importés, etc.

Excel est une bonne démonstration: dans la version anglaise, il utilise "," comme séparateur. En Allemagne, il utilise ";". Donc, une version allemande s'étouffe avec les fichiers CSV anglais, et vice versa ...

Sa principale force est la lisibilité humaine, qui ne doit pas être écartée. Mais je ne m'y fierais pas comme format de stockage, il est trop fragile à cet effet. Si vous devez exporter des fichiers pour les humains, vous pouvez utiliser CSV mais même dans ce cas, j'essaierais d'utiliser une bibliothèque qui écrit dans des fichiers xlsx (ils sont disponibles gratuitement).

En général NO. Pourquoi? JSON et XML sont là pour se débarrasser du CSV tant redouté. Ce sont les approches structurées de ce qui a été fait sans structure avec CSV depuis longtemps. Oui, dans certains cas d'utilisation, le CSV est toujours préféré, mais en général, dans 9 cas sur 10, il vaut mieux ne pas utiliser le CSV.