¿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?
fuente
Respuestas:
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.
fuente
write('"');write(fld1);write('"');ad nauseum). Luego, omiten poner comillas alrededor de algo. Luego escriben su propio analizador ...Permítanme arrojar algunos puntos a favor de CSV:
fuente
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.
fuente
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.
fuente
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.
fuente
Primero, estoy de acuerdo en que hay algunos problemas muy reales con el formato:
NULLy'', lo cual es un problema al importar archivos CSV a bases de datos SQL.&#xNNNN;o JSON\uNNNN) significa que no hay una forma estándar de representar caracteres de control o caracteres no ASCII.Pero en la otra mano:
fuente
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.
fuente
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.
fuente
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 ...
fuente
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. . .
fuente
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
fuente
¿Por qué lo uso?
etcétera etcétera.
fuente