CSV est-il une bonne alternative à XML et JSON?
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 dans 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 vraiment courant dans certaines industries lorsqu'il s'agit de systèmes et de workflows 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", pensez à 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 graphiques 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 les deux le même objet qu'un membre)
- objets de différents types à sérialiser dans le même document
Nous voulons en outre être en mesure de désérialiser de manière fiable les objets de notre format de stockage.
XML
Est principalement un langage extensible balisage. 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 un objet simple arbres. Il n'y a pas de support pour les graphiques généraux. JSON n'a pas de concept type au-delà des primitives chaîne, entier, flottant, booléen , null et les types de collection array et object.
YAML
Le plus facilement compris comme une extension de JSON. A une notion de alias qui permet de créer des graphes d'objets de complexité arbitraire. A un concept de métadonnées comme tags qui peut être utilisé 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 suffisamment 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. J'ai beaucoup vu cela 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 construisait des graphiques pour nous et il avait 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 bootstrap 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 exprimant la complexité, et certainement XML n'était pas meilleur pour exprimer les structures de graphe que CSV. JSON est beaucoup plus agréable (et terser) que XML mais est similaire à bien des égards donc je m'attendrais à 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 d'échappement, de 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 OK 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).