Por que continuamos usando CSV? [fechadas]

Por que continuamos usando CSV?

Recentemente, mudei para o trabalho no domínio da saúde e, apesar do maravilhoso trabalho nos padrões de transferência de dados, toda a transferência de dados é em CSV , tanto para relatórios para organizações externas quanto para migrações de dados ao implementar novos sistemas.

Infelizmente, o uso de CSV é a causa da repetição sem fim dos mesmos erros estúpidos, com o mesmo desperdício de tempo do desenvolvedor. (escape ruim, falha ao manipular campos nulos etc.)

Eu sei que podemos fazer melhor, e qualquer coisa entre JSON e XML (dependendo da instância) ficaria bem. (Na maioria das vezes, são dados passando de um MS SQLserver 2005 para outro!)

Sinto como se cada vez que vejo isso acontecendo, estou literalmente assistindo a um desenvolvedor desperdiçar mais tempo.

Então, por que continuamos nos moldando? Quando vamos parar?

No seu caso, parece que o CSV não é um bom ajuste devido à falta de especificação rígida.

Para dados não triviais, não é a escolha certa.

Por que / quando o CSV é uma boa escolha? Provavelmente muitas instâncias para mencionar, os benefícios da simplicidade para dados simples são óbvios. Desde que os dados sejam higienizados / escapados corretamente, não há problemas. De um modo geral, todos esses casos seriam simples / triviais. Obviamente, o delimitador padrão que aparece no conteúdo costuma ser um problema ao lidar com CSV.

Mas se você está fazendo algo mais envolvido do que conseguir que um cliente não técnico envie dados de uma planilha do Excel ou de algum outro caso de uso semelhante, o CSV provavelmente é insuficiente para qualquer uso sério.

XML é um ajuste muito melhor (sim, ainda mais que JSON), pois você é capaz de fazer especificações de esquema padronizadas detalhadas para ele. (Sem mencionar que as especificações / esquemas desfrutam da flexibilidade de vários estilos de implementação, XSD, DTD e Relax NG)

Para sistemas de circuito fechado, especialmente onde a largura de banda é uma preocupação, o JSON pode ser mais adequado que o XML, mas a falta de linguagem (s) de especificação de esquema geralmente a impede de aplicativos de nível corporativo.

Deixe-me jogar alguns pontos a favor do CSV:

• O CSV é simples (r do que qualquer alternativa sugerida no OP) para implementar e analisar
• O CSV é entendido por quase todos os softwares do planeta (passado e presente)
• O CSV força um esquema bastante plano e simples (há uma única lista plana de campos)
• O CSV é mais legível por humanos que XML, JSON ou (UGH!) HL7 (V2.x, pré-xml)

Compatibilidade com versões anteriores. Se o serviço da web de organizações externas manipular CSV e todas as suas ferramentas existentes manipularem CSV, nenhuma das partes terá motivação para migrar para um novo serviço. Por que sua organização externa começou a oferecer suporte a um formato diferente? Ninguém com quem trabalham pode usá-lo! Por que você começaria a produzir um formato diferente? Nenhuma das organizações com as quais você trabalha aceita!

O verdadeiro problema que vejo aqui é: por que seus desenvolvedores lançam seu próprio código CSV toda vez? Se eles usassem uma biblioteca CSV estável e sólida, eles não teriam os problemas que você descreve. Os problemas são causados ​​pelos desenvolvedores lançando sua própria solução em vez de usar uma biblioteca, e sinceramente não vejo como a migração para JSON ou XML corrige isso de maneira mágica. Você ainda teria pessoas tentando aumentá-las em vez de usar uma biblioteca.

O CSV é um pouco mais rápido , menor em tamanho , muito fácil de manusear (mesmo no Excel) e muitos aplicativos existentes entendem, é um padrão amplamente usado .

Ainda é a primeira escolha em muitas situações.

Eu pessoalmente ainda gosto muito desse formato. Mas também uso o JSON, mas para outros aplicativos como a interface do usuário da web.

Primeiro e acima de tudo, porque apesar de consumir dados CSV pode ser (um pouco) não trivial, gerá-los é extremamente fácil.

Eu também apontaria que nem JSON nem XML são realmente mais fáceis de acertar (tanto para o produtor quanto para o consumidor). De fato, mal é preciso olhar em volta para saber que muitas pessoas tentam usar expressões regulares para analisar dados XML, mesmo que não haja dúvida de que isso não pode e não funcionará.

A maioria dos problemas que podem (e ocorrem) com o CSV também pode (e ocorre) com JSON e XML. O XML, em particular, adiciona muitos outros problemas em potencial. Uma biblioteca para analisar dados XML geralmente é maior, mais lenta e mais difícil de usar do que uma biblioteca semelhante para dados CSV.

Primeiro, concordo que há alguns problemas reais com o formato:

• É digitado rigorosamente.
  • Sem fazer distinção entre valores numéricos e de texto, o Excel irá adivinhar errado e estragar seus códigos postais e números de cartão de crédito.
  • Não há uma maneira padrão de representar dados binários.
  • Não há uma maneira padrão de distinguir entre NULLe '', o que é um problema ao importar arquivos CSV para bancos de dados SQL.
• Suporte deficiente para "caracteres especiais".
  • A falta de referências de caracteres numéricos como (XML &#xNNNN;ou JSON \uNNNN) significa que não há uma maneira padrão de representar caracteres de controle ou caracteres não ASCII.
  • Muitas implementações não implementam corretamente quebras de linha em um campo.
• A falta de um padrão. Existe o RFC 4180 , mas não é seguido universalmente.

Mas por outro lado:

• As alternativas são piores. JSON e XML, projetados em torno de árvores, são pouco adequados para dados baseados em tabela, especificamente em termos de ...
• COMPACIDADE! No XML, você precisa ter uma marca de início e uma marca de fim para cada coluna em cada linha. No CSV, você escreve apenas os cabeçalhos das colunas uma vez.
• CSV é muito fácil de gerar.
• Não programadores podem abrir arquivos CSV no Excel.

Como muitos analistas usam o Excel (para tabelas dinâmicas e outras), e é muito mais fácil gerar CSV do que gerar o formato nativo do Excel.

Nota de rodapé: dados os problemas que eu já vi no Excel de lidar com arquivos CSV, como remover zeros à esquerda e perder precisão, essa provavelmente é uma falsa sensação de ser mais fácil.

Se há algo errado com o CSV, é que o CSV parece tão simples que muitos desenvolvedores tentam inventar seus próprios analisadores / gravadores e depois culpam o CSV por não lidar com a fuga corretamente. Com um bom analisador de CSV (muitos bons por aí), não haverá nenhum problema.

Alguém mencionou que o CSV não é bom para dados não triviais, mas não concordo. O XML permite dados não triviais, porque diferentes conjuntos de dados podem ser colocados em diferentes tags "container". Com o CSV, você sempre pode colocar dados diferentes em arquivos diferentes para obter o mesmo efeito.

Além disso, na minha opinião, o uso de XML para transferência de dados contraria fundamentalmente o objetivo do XML - a transferência de dados geralmente implica um contrato estável entre fornecedores e consumidores, enquanto o XML visa transportar informações expansíveis sujeitas a interpretação quando consumidas.

Eu acho que o CSV é bom quando você tem apenas dados de texto simples, com apenas vírgulas e ponto-e-vírgula / linha final no final.

Dados arquitetados em árvore ou dados compostos dificilmente podem ser usados ​​com CSV.

CSV é apenas uma matriz 2D simples de texto como no Excel, nada muito ...

É realmente tudo sobre mainframes e excel aqui.

Mainframes porque esses sistemas antigos descobriram como se comunicar usando CSV. Portanto, os grandes aplicativos que despejam os dados podem lê-los e gravá-los e não têm motivos para mudar agora.

Excel porque ele pode abrir CSVs diretamente. De fato, ele assume a extensão .csv quando você a instala. Os usuários apenas clicam no ícone do excel, que parece um pouco engraçado, e ele abre e cria uma grade agradável com a qual eles podem se familiarizar.

Agora, as versões modernas do excel são capazes de ler, digamos, XML diretamente. Mas, para fazer isso, o usuário precisa entender um pouco mais do que "clicar duas vezes nessa imagem". E clicar duas vezes na imagem certa pode ser pedir demais em alguns setores. . .

Eu já vi muitas respostas técnicas, mas desconfio que o motivo pelo qual as pessoas usam o CSV é o mesmo porque as pessoas usam muitas outras técnicas / tecnologias: porque é a que elas estão mais familiarizadas

por que eu uso isso?

1. o cliente quer
2. é mais rápido que xml na rede (carga de rede menor)
3. nada mais complexo é necessário para transmitir os dados
4. plataforma cruzada
5. legível por humanos
6. fácil de implementar leitores e escritores para ele

etc etc.