¿Por qué seguimos usando CSV? [cerrado]

¿Por qué seguimos usando CSV?

Recientemente hice un cambio para trabajar en el dominio de la salud y, a pesar del maravilloso trabajo en los estándares de transferencia de datos, toda la transferencia de datos se realiza en CSV , tanto para informar a organizaciones externas como para migraciones de datos al implementar nuevos sistemas.

Desafortunadamente, el uso de CSV es la causa de la repetición interminable de los mismos errores estúpidos, con la misma pérdida de tiempo del desarrollador. (mal escape, no se pueden manejar campos nulos, etc.)

Sé que podemos hacerlo mejor, y cualquier cosa entre JSON y XML (dependiendo de la instancia) estaría bien. (¡La mayoría de las veces se trata de datos que van de un MS SQLserver 2005 a otro!)

Siento que cada vez que veo que esto sucede, estoy literalmente viendo a un desarrollador perder el tiempo.

Entonces, ¿por qué seguimos haciéndonos unos a otros? ¿Cuándo nos detendremos?

En su caso, parece que CSV no es una buena opción debido a su falta de especificaciones estrictas.

Para datos no triviales no es la elección correcta.

¿Por qué / cuándo es CSV una buena opción? Probablemente demasiadas instancias para mencionar, los beneficios de la simplicidad para los datos planos son obvios. Mientras los datos se desinfecten / escapen correctamente, no hay problemas. Sin embargo, en términos generales, todos estos casos serían simples / triviales. Por supuesto, el delimitador estándar que aparece en el contenido es a menudo un dolor cuando se trata de CSV.

Pero si está haciendo algo más complicado que conseguir que un cliente no técnico envíe datos desde una hoja de Excel u otro caso de uso similar, entonces el CSV probablemente sea insuficiente para cualquier uso serio.

XML encaja mucho mejor (sí, incluso más que JSON) ya que puede hacer una especificación de esquema estandarizado detallado para él. (Sin mencionar que las especificaciones / esquemas disfrutan de la flexibilidad de múltiples estilos de implementación, XSD, DTD y Relax NG)

Para los sistemas de circuito cerrado, especialmente cuando el ancho de banda es una preocupación, JSON puede adaptarse mejor que XML, pero la falta de lenguaje (s) de especificación de esquema a menudo lo excluye de las aplicaciones de nivel empresarial.

Permítanme arrojar algunos puntos a favor de CSV:

• CSV es simple (r que cualquier otra alternativa sugerida en OP) para implementar y analizar
• CSV es entendido por casi todas las piezas de software en el planeta (pasado y presente)
• CSV fuerza un esquema bastante plano y simple (hay una sola lista plana de campos)
• CSV es más legible para los humanos que XML, JSON o (UGH!) HL7 (V2.x, pre-xml)

Compatibilidad al revés. Si su servicio web de organizaciones externas maneja CSV, y todas sus herramientas existentes manejan CSV, ninguna de las partes tiene ninguna motivación para pasar a un nuevo servicio. ¿Por qué su organización externa comenzaría a admitir un formato diferente? ¡Nadie con quien trabajen puede usarlo! ¿Por qué comenzarías a producir un formato diferente? ¡Ninguna de las organizaciones con las que trabaja lo acepta!

El problema real que veo aquí es, ¿por qué sus desarrolladores están lanzando su propio código CSV cada vez? Si usaran una biblioteca CSV estable y sólida como una roca, no tendrían los problemas que usted describe. Los problemas son causados ​​por los desarrolladores que implementan su propia solución en lugar de usar una biblioteca, y honestamente no veo cómo cambiar eso mágicamente a JSON o XML. Todavía tendrías gente tratando de regexearlos en lugar de usar una biblioteca.

CSV es un poco más rápido , de menor tamaño , muy fácil de manejar (incluso en Excel) y muchas aplicaciones existentes lo entienden, es un estándar ampliamente utilizado .

Sigue siendo una primera opción en muchas situaciones.

Personalmente, todavía me gusta mucho ese formato. Pero también uso JSON, pero para otras aplicaciones como la interfaz de usuario web.

En primer lugar, porque aunque consumir datos CSV puede ser (ligeramente) no trivial, generarlos es extremadamente fácil.

También señalaría que ni JSON ni XML son realmente más fáciles de corregir (ya sea para el productor o el consumidor). De hecho, uno apenas tiene que mirar para saber que mucha gente trata de usar expresiones regulares para analizar datos XML, aunque no hay absolutamente ninguna duda de que hacerlo no puede funcionar y no funcionará.

La mayoría de los problemas que pueden surgir (y lo hacen) con CSV también pueden surgir (y lo hacen) con JSON y XML. XML, en particular, agrega muchos más problemas potenciales propios. Una biblioteca para analizar datos XML es generalmente más grande, más lenta y más difícil de usar que una biblioteca similar para datos CSV.

Primero, estoy de acuerdo en que hay algunos problemas muy reales con el formato:

• Está escrito a máquina.
  • Sin distinción entre texto y valores numéricos, Excel adivinará mal y arruinará sus códigos postales y números de tarjetas de crédito.
  • No hay una forma estándar de representar datos binarios.
  • No hay una forma estándar de distinguir entre NULLy '', lo cual es un problema al importar archivos CSV a bases de datos SQL.
• Mal soporte para "caracteres especiales".
  • La falta de referencias de caracteres numéricos como (XML &#xNNNN;o JSON \uNNNN) significa que no hay una forma estándar de representar caracteres de control o caracteres no ASCII.
  • Muchas implementaciones no implementan saltos de línea correctamente dentro de un campo.
• La falta de un estándar. Hay RFC 4180 , pero no se sigue universalmente.

Pero en la otra mano:

• Las alternativas son peores. JSON y XML, diseñados alrededor de árboles, no se ajustan a los datos basados ​​en tablas, específicamente en términos de ...
• COMPACTACIÓN! En XML, debe tener una etiqueta de inicio y una etiqueta de finalización para cada columna de cada fila. En CSV, solo escribe los encabezados de columna una vez.
• CSV es muy fácil de generar.
• Los no programadores pueden abrir archivos CSV en Excel.

Debido a que muchos analistas usan Excel (para tablas dinámicas y demás), y es mucho más fácil generar CSV que generar el formato nativo de Excel.

Nota al pie: dada la cantidad de problemas que he visto con Excel al manejar archivos CSV, como eliminar los ceros iniciales y perder precisión, esta es probablemente una falsa sensación de ser más fácil.

Si hay algo mal con CSV, es que CSV parece tan simple que muchos desarrolladores intentan inventar sus propios analizadores / escritores y luego culpan a CSV por no manejar el escape correctamente. Con un buen analizador CSV (muchos buenos), no habrá ningún problema.

Alguien mencionó que CSV no es bueno para datos no triviales, pero no estoy de acuerdo. XML permite datos no triviales porque se pueden poner diferentes conjuntos de datos en diferentes etiquetas de "contenedor". Con CSV, siempre puede poner diferentes datos en diferentes archivos para lograr el mismo efecto.

Además, en mi opinión, el uso de XML para la transferencia de datos va fundamentalmente en contra del propósito de XML: la transferencia de datos generalmente implica un contrato estable entre proveedores y consumidores, mientras que XML está destinado a transportar información expandible sujeta a interpretación cuando se consume.

Supongo que CSV es bueno cuando solo tiene datos de texto simples, con solo comas y punto y coma / línea final al final.

Los datos de arquitectura de árbol o los datos compuestos difícilmente se pueden usar con CSV.

CSV es solo una simple matriz de texto en 2D como en Excel, nada más ...

Realmente se trata de mainframes y Excel aquí.

Mainframes porque esos viejos sistemas descubrieron cómo comunicarse usando CSV. Entonces, las grandes aplicaciones que descargan los datos pueden leerlos y escribirlos y no tienen ninguna razón para cambiar ahora.

Excel porque puede abrir CSV directamente. De hecho, se hace cargo de la extensión .csv cuando la instala. Los usuarios simplemente hacen clic en el icono de Excel de aspecto un poco divertido y se abre y forma una cuadrícula agradable con la que pueden discutir.

Ahora, las versiones modernas de Excel son bastante capaces de leer, digamos, XML, directamente. Pero para hacerlo, un usuario tiene que entender un poco más que "hacer doble clic en esa imagen". Y hacer doble clic en la imagen correcta puede ser demasiado pedir en algunas industrias. . .

He visto muchas respuestas técnicas, pero sospecho que la razón por la que las personas usan CSV es la misma razón por la que las personas usan muchas otras técnicas / tecnologías: porque es con la que están más familiarizadas

¿Por qué lo uso?

1. el cliente lo quiere
2. es más rápido que xml en la red (menor carga de red)
3. no se necesita nada más complejo para transmitir los datos
4. plataforma cruzada
5. legible por humanos
6. fácil de implementar lectores y escritores para ello

etcétera etcétera.