JSON/xml/autres languages a balises sont plutôt mauvais pour le transfert de données brutes à large échelle.
CSV, c’est une ligne une donnée, donc trivial a streamer, le parseur est très simple à écrire, ça se parallélise très bien, tu sais combien de données t’es censé avoir d’entree de jeu, trivial de se rappeler ou tu t’es arrêté. Tout ça est très avantageux quand il s’agit de faire un dump d’une db et le réimporter dans une autre.
xml et json ont généralement des parseurs en stream, mais plus durs à utiliser, et ils ont aussi beaucoup plus d’overhead (noms des champs répétés à chaque entrée).
Le gros intérêt de json c’est qu’il mappe directement a des objets (le o de json), et est super flexible niveau schéma. Ces 2 points n’ont que peu d’intérêt si tu veux charger 10 000 lignes dans une base de données (ou dans Excel).
Bref, pour faire de l’échange de données dans le cas cité, csv reste le plus simple et pratique.
[^] # Re: JSON? YAML?’
Posté par groumly . En réponse au journal En finir avec CSV ou Excel pour échanger des données. Évalué à 10.
JSON/xml/autres languages a balises sont plutôt mauvais pour le transfert de données brutes à large échelle.
CSV, c’est une ligne une donnée, donc trivial a streamer, le parseur est très simple à écrire, ça se parallélise très bien, tu sais combien de données t’es censé avoir d’entree de jeu, trivial de se rappeler ou tu t’es arrêté. Tout ça est très avantageux quand il s’agit de faire un dump d’une db et le réimporter dans une autre.
xml et json ont généralement des parseurs en stream, mais plus durs à utiliser, et ils ont aussi beaucoup plus d’overhead (noms des champs répétés à chaque entrée).
Le gros intérêt de json c’est qu’il mappe directement a des objets (le o de json), et est super flexible niveau schéma. Ces 2 points n’ont que peu d’intérêt si tu veux charger 10 000 lignes dans une base de données (ou dans Excel).
Bref, pour faire de l’échange de données dans le cas cité, csv reste le plus simple et pratique.