¿Es CSV una buena alternativa a XML y JSON? [cerrado]

¿Se considera CSV una buena opción contra XML y JSON para lenguajes de programación?

Generalmente uso XML y JSON (o, a veces, un archivo de texto sin formato) como almacenamiento de archivos sin formato. Sin embargo, recientemente me encontré con una implementación de CSV en PHP . Sin embargo, generalmente he visto CSV utilizado para entradas en archivos de Excel , pero nunca lo he usado con la programación. ¿Sería mejor que XML o JSON de alguna manera?

La respuesta es, depende.

CSV es ideal para ciertos casos de uso. Por ejemplo, como formato de "transmisión" para grandes conjuntos de datos, es más fácil de transmitir que XML / JSON, y los archivos CSV ocupan mucho menos espacio de almacenamiento. Lo uso para transmitir conjuntos de datos en el rango de gigabytes donde otros formatos no son prácticos.

También es muy común en ciertas industrias cuando se trata de sistemas y flujos de trabajo heredados. Intente importar JSON a MS Excel.

La ODI comentó recientemente sobre CSV, llamando a 2014 "El año de CSV"

Para un formato CSV "adecuado", considere usar el tipo mime CSV en sus respuestas HTTP.

Ciertamente no.

CSV es un formato de tabla que se asigna muy bien a conjuntos de datos u otros datos tabulares. ¡Pero no todos los datos son tabulares! En general, queremos serializar gráficos de objetos . Esto puede ser difícil en los siguientes casos:

• referencias circulares
• subgrafos compartidos (por ejemplo, dos objetos que contienen el mismo objeto que un miembro)
• objetos de diferentes tipos para ser serializados en el mismo documento

Además, queremos poder deserializar de manera confiable los objetos de nuestro formato de almacenamiento.

XML

Es principalmente un lenguaje de marcado extensible . También puede ser utilizado para almacenar estructuras de datos generales. El soporte de idiomas para ID significa que se pueden crear gráficos complejos, aunque es mejor usarlo para árboles. Se puede probar la corrección de un documento según una especificación Hay varios problemas con este formato que pueden hacer que no sea práctico, como la extrema verbosidad.

JSON

Es principalmente una forma de almacenar árboles de objetos simples . No hay soporte para gráficos generales. JSON no tiene ningún concepto de tipo más allá de las primitivas string , integer , float , boolean , null y la colección de tipos array y object .

Ñame

Más fácilmente entendido como una extensión de JSON. Tiene una noción de alias que permiten crear gráficos de objetos de complejidad arbitraria. Tiene un concepto de metadatos como etiquetas que se pueden usar para escribir correctamente.

CSV

No tiene nada, excepto una sola mesa. Si queremos almacenar gráficos de objetos, tendríamos que usar un esquema como

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

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

Hay muchos dialectos de CSV que no están de acuerdo con delimitadores, terminadores de línea, comillas, caracteres de escape y muchos otros problemas que lo hacen inadecuado para datos generales (binarios). Todo esto hace que sea bastante difícil procesar datos CSV.

Básicamente, las cosas fáciles son difíciles o imposibles con CSV cuando se usa como formato de serialización general.

Esta crítica no se aplica cuando se usa para almacenar datos verdaderamente tabulares como hojas de tiempo o una serie de mediciones. Aquí, CSV (a menudo en la variante de valores separados por tabulaciones) suele ser más compacto y más fácil de usar que los otros formatos de datos.

También tengo que decir que depende de lo que intentes lograr. Para muchos problemas, no importa mucho lo que elija si el problema es lo suficientemente pequeño y su elección encaja bien con el sistema existente.

Tomar un sistema heredado e intentar calzar un nuevo formato a veces puede ser un problema, ya que introdujo más complejidad y tiene un nuevo sistema de entrada para depurar. Lo he visto mucho cuando las personas nuevas prefieren algo diferente de lo que existe, o cuando aparece un nuevo formato y quieren experimentar con él. Esto puede o no ser una buena idea, depende de las circunstancias.

Hace años trabajé en un sistema de base de datos de gráficos de investigación que dependía de archivos CSV de varios formatos. El importador de archivos CSV construyó gráficos para nosotros y tuvo muchos años de trabajo para depurar y optimizar el código. Fue a la vez rápido y flexible y nos encantaría usarlo para iniciar grandes proyectos de investigación. Cuando apareció XML en la escena, agregamos un importador de XML, pero no fue necesariamente una mejora en términos de velocidad o complejidad de expresión, y ciertamente XML no fue mejor para expresar estructuras gráficas que CSV. JSON es mucho mejor (y más terser) que XML pero es similar en muchos aspectos, por lo que esperaría un resultado similar al crear un nuevo importador en ese sistema.

En un momento dado, un cliente trajo una cantidad masiva de datos en formato "cobol" (como lo llamamos), archivos con líneas de longitud variable que contienen marcadores que indican cómo interpretar los bytes que siguieron en esa línea. Vino de una época en que el almacenamiento era costoso, por lo que la compacidad era un requisito. Importamos esos datos al convertirlos en formato CSV sobre la marcha y alimentarlos al importador CSV. Eso fue fácil de hacer y minimizó la cantidad de depuración y mantenimiento, que son cosas buenas. Si tuviéramos que importar ese tipo de datos todo el tiempo, podríamos haberlo incorporado directamente al sistema para obtener ganancias de rendimiento y eficiencia.

Por lo tanto, depende de lo que esté haciendo y de lo que haga el sistema subyacente. En mi ejemplo, el importador de CSV fue sólidamente diseñado y confiable. Dudaría en decirte que un formato fue mejor o peor sin entender lo que está sucediendo en las otras capas que estoy construyendo. Me encanta JSON y lo prefiero, pero sé que dadas ciertas estructuras de datos complejas y conjuntos de datos lo suficientemente grandes, los archivos CSV también pueden funcionar muy bien.

No.

CSV no es realmente un formato único. Hay una gran variedad de estilos para escapar, separadores y otros problemas de formato que tienen muchos archivos CSV en la naturaleza.

Si va a usar esto como un almacenamiento de archivos planos, usar JSON le servirá mucho mejor. JSON se asigna hacia y desde objetos con mucho menos problemas de los que tendrá que hacer un CSV para hacerlo.

Yo recomendaría encarecidamente que no. Podría estar bien para generar CSV en algún momento (si el usuario lo solicita). Pero es un mal ajuste para fines de almacenamiento / importación. Esto se debe principalmente al hecho de que "CSV" está muy mal definido. ¿La "C" indica "coma" o "carácter" separados? ¿Cómo trata las cadenas de texto que contienen caracteres de escape como "? Cada maldita implementación de CSV trata los caracteres de escape, etc. de manera diferente, lo que conduce a archivos que pueden ser ex, pero no importados, etc.

Excel es una buena demostración: en la versión en inglés usa "," como separador. En Alemania, usa ";". Entonces, una versión alemana se ahoga en archivos CSV en inglés, y viceversa ...

Su principal fortaleza es la legibilidad humana, que no debe descartarse. Pero no confiaría en él como formato de almacenamiento, es demasiado frágil para ese propósito. Si tiene que exportar archivos para humanos, puede usar CSV pero incluso entonces trataría de usar una biblioteca que escriba en archivos xlsx (están disponibles gratuitamente).

En general NO. ¿Por qué? JSON y XML están ahí básicamente para deshacerse del temido CSV. Son los enfoques estructurados de lo que se ha hecho sin estructurar con CSV durante mucho tiempo. Sí, hay algunos casos de uso en los que todavía se prefiere CSV, pero en general en 9 de cada 10 casos es mejor no usar CSV.