O CSV é uma boa alternativa ao XML e JSON? [fechadas]


22

O CSV é considerado uma boa opção contra XML e JSON para linguagens de programação?

Eu geralmente uso XML e JSON (ou às vezes um arquivo de texto sem formatação) como armazenamento de arquivo simples. No entanto, recentemente me deparei com uma implementação CSV em PHP . No entanto, geralmente vi o CSV usado para entradas em arquivos do Excel , mas nunca o usei com programação. Seria melhor do que XML ou JSON de alguma forma?


3
Esta citação é vaga. Você está perguntando se o CSV cria um formato melhor como sistema de armazenamento ou se há algum motivo para usar o CSV sobre XML / JSON?
GrandmasterB

4
Qualquer estrutura de mensagem CSV pode ser mapeada para um formato de mensagem XML ou JSON. Nem todo o formato de mensagem XML / JSON pode ser mapeado para CSV. Portanto, o CSV cobre apenas um caso de uso de dados específico, formato tabular, onde JSON e XML podem abranger estruturas de mensagens mais complexas.
Jon Raynor

@ JonRaynor: Eu acho que qualquer formato XML ou JSON pode ser mapeado para CSV - mas não de forma limpa. Você teria que inventar alguma maneira de representar a estrutura da árvore. O resultado seria feio e quase certamente não vale a pena ser implementado. Para quase todos os fins práticos, você está certo.
Keith Thompson

@KeithThompson foi inventado :)
Eliran Malka

Respostas:


41

A resposta é: depende.

O CSV é ótimo para certos casos de uso. Por exemplo, como um formato de "streaming" para grandes conjuntos de dados, é mais fácil transmitir do que XML / JSON, e os arquivos CSV ocupam muito menos espaço de armazenamento. Eu o uso para transmitir conjuntos de dados na faixa de gigabytes, onde outros formatos são impraticáveis.

Também é muito comum em certos setores quando se lida com sistemas e fluxos de trabalho herdados. Tente importar JSON para o MS Excel.

O ODI comentou recentemente sobre o CSV, chamando 2014 de "O ano do CSV"

Para formatação CSV "adequada", considere usar o tipo mime CSV em suas respostas HTTP.


2
+1 para sistemas legados; enquanto o sistema legado pode não estar usando o CSV em uma forma pretendida (Eu recentemente tive que lidar com a importação de um arquivo CSV que foi, honestamente, um relatório, não uma tabela), que não tem que lidar com informações legado em todo o mundo .
Brian S

1
O CSV tem a vantagem de streaming, o que é muito importante: o analisador de CSV tem muito menos estado para lidar do que os analisadores JSON ou XML.
Matt

22

Certamente que não.

CSV é um formato de tabela que mapeia muito bem para conjuntos de dados ou outros dados tabulares. Mas nem todos os dados são tabulares! Geralmente, queremos serializar gráficos de objetos . Isso pode ser difícil nos seguintes casos:

  • referências circulares
  • subgráficos compartilhados (por exemplo, dois objetos que contêm o mesmo objeto que um membro)
  • objetos de tipos diferentes para serem serializados no mesmo documento

Além disso, queremos ser capazes de desserializar de maneira confiável os objetos do nosso formato de armazenamento.

XML

É principalmente uma linguagem de marcação extensível . Pode ser otimizado para armazenar estruturas de dados gerais também. O suporte ao idioma para IDs significa que gráficos complexos podem ser criados, embora seja melhor usado para árvores. Um documento pode ser testado quanto à exatidão em relação a uma especificação. Existem vários problemas com esse formato que podem torná-lo impraticável, como a extrema verbosidade.

JSON

É principalmente uma maneira de armazenar árvores de objetos simples . Não há suporte para gráficos gerais. JSON não tem conceito de tipo além das primitivas string , integer , float , boolean , null e os tipos de coleção array e objeto .

YAML

Mais facilmente entendido como uma extensão do JSON. Possui uma noção de alias que permite a criação de gráficos de objetos de complexidade arbitrária. Possui um conceito de metadados, como tags, que podem ser usadas para a digitação correta.

CSV

Não tem nada, exceto uma única mesa. Se quisermos armazenar gráficos de objetos, teríamos que usar um esquema como

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

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

Existem muitos dialetos de CSV que discordam de delimitadores, terminadores de linha, citações, caracteres de escape e muitos outros problemas que o tornam inadequado para dados gerais (binários). Tudo isso dificulta o processamento de dados CSV.

Então, basicamente, coisas fáceis são difíceis ou impossíveis com o CSV ao usá-lo como um formato geral de serialização.

Essa crítica não se aplica ao usá-lo para armazenar dados verdadeiramente tabulares, como folhas de ponto ou uma série de medições. Aqui, o CSV (geralmente na variante de valores separados por tabulação) é geralmente mais compacto e fácil de usar do que os outros formatos de dados.


1
Eu acho que esse é um argumento justo. Eles são diferentes, então use-os para coisas diferentes, use cada um onde for melhor.
Ben

1
Sem a primeira linha, isso seria uma boa resposta. O CSV é uma boa alternativa ao XML para obter informações tabulares (um arquivo SQLite distribuível provavelmente é melhor que ambos). Mas, como você explica para os dados tabulares, é a escolha de arquivo superior.

4

Eu também tenho que dizer que depende do que você está tentando alcançar. Para muitos problemas, não importa muito o que você escolher se o problema for pequeno o suficiente e sua escolha se encaixar bem no sistema existente.

Às vezes, pegar um sistema legado e tentar calçar sapatos em um novo formato pode ser um problema, pois você introduziu mais complexidade e possui um novo sistema de entrada para depuração. Eu já vi isso muito quando novas pessoas preferem algo diferente do que existe, ou quando um novo formato aparece e elas querem experimentar. Isso pode ou não ser uma boa ideia, depende das circunstâncias.

Anos atrás, trabalhei em um sistema de banco de dados de gráficos de pesquisa que dependia de arquivos CSV de vários formatos. O importador de arquivos CSV criaria gráficos para nós e ele tinha muitos anos de trabalho para depurar e otimizar o código. Era rápido e flexível e nós o usaríamos com prazer para iniciar grandes projetos de pesquisa. Quando o XML apareceu em cena, adicionamos um importador de XML, mas não foi necessariamente uma melhoria em termos de velocidade ou complexidade de expressão, e certamente o XML não era melhor em expressar estruturas de gráficos que o CSV. O JSON é muito melhor (e mais terser) que o XML, mas é semelhante em muitos aspectos, portanto, esperaria um resultado semelhante ao criar um novo importador nesse sistema.

Em um determinado momento, um cliente trouxe uma quantidade massiva de dados no formato "cobol" (arquivos que chamamos de "cobol"), arquivos com linhas de comprimento variável contendo marcadores que indicavam como interpretar os bytes que se seguiam nessa linha. Veio de uma época em que o armazenamento era caro, portanto a compactação era um requisito. Importamos esses dados convertendo-os para o formato CSV em tempo real e alimentando-os no importador de CSV. Isso foi fácil de fazer e minimizou a quantidade de depuração e manutenção, o que é bom. Se tivéssemos que importar esse tipo de dados o tempo todo, poderíamos incorporá-lo diretamente no sistema para obter ganhos de desempenho e eficiência.

Portanto, depende do que você está fazendo e do que o sistema subjacente faz. No meu exemplo, o importador de CSV foi solidamente projetado e confiável. Eu hesitaria em dizer que um formato era melhor ou pior sem entender o que está acontecendo nas outras camadas que estou construindo. Adoro o JSON e prefiro, mas sei que, devido a certas estruturas de dados complexas e conjuntos de dados grandes o suficiente, os arquivos CSV também podem funcionar muito bem.


3

Não.

CSV não é realmente um único formato. Existe uma grande variedade de estilos para escape, separadores e outros problemas de formatação que muitos arquivos CSV em estado selvagem têm.

Se você estiver usando isso como um armazenamento de arquivo simples, o uso do JSON o servirá muito melhor. O JSON mapeia para e de objetos com muito menos problemas do que você terá que julgar o CSV para fazer isso.


0

Eu recomendaria fortemente contra isso. Talvez eu esteja bem em enviar CSV em algum momento (se o usuário solicitar). Mas é um ajuste inadequado para fins de armazenamento / importação. Isso se deve principalmente ao fato de "CSV" estar muito mal definido. O "C" indica "vírgula" ou "caractere" separados? Como você trata seqüências de texto que contêm caracteres de escape como "? Toda implementação maldita de CSV trata caracteres de escape etc. de maneira diferente, o que leva a arquivos que podem ser excluídos, mas não importados, etc.

O Excel é uma boa demonstração: na versão em inglês, ele usa "," como separador. Na Alemanha, ele usa ";". Então, uma versão em alemão engasga com arquivos CSV em inglês e vice-versa ...

Sua principal força é a legibilidade humana, que não deve ser descartada. Mas eu não confiaria nele como um formato de armazenamento, é muito quebradiço para esse fim. Se você precisar exportar arquivos para humanos, poderá usar o CSV, mas mesmo assim eu tentaria usar uma biblioteca que grava em arquivos xlsx (eles estão disponíveis gratuitamente).


3
É "vírgula", veja RFC 4180 . Só porque a Microsoft quebrou algo na Alemanha não significa um formato padronizado é inútil ...
Ben

Não, não é "vírgula" - também pode significar "caráter separado" e o problema não se limita à Alemanha. Sim, o RFC especifica o contrário, mas um arquivo chamado "csv" pode conter um upload de diferentes tipos de separadores, estilos de escape etc. Quando você tenta importar um arquivo desse tipo, seu programa importa ... algo, mas não o que você deseja.
Christian Sauer

Esta resposta identifica armadilhas importantes contra o CSV.
Gdbj 15/04

-3

Em geral, NO. Por quê? JSON e XML existem basicamente para se livrar do temido CSV. São as abordagens estruturadas do que foi feito não estruturado com CSV por um longo tempo. Sim, existem alguns casos de uso em que o CSV ainda é o preferido, mas em geral em 9 de 10 casos é melhor não usar o CSV.


7
A menos, é claro, que os dados que você está transferindo sejam "simples". Você economiza uma quantia enorme ao não transferir tags XML inúteis etc.
Ben
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.