XML vs archivos de texto delimitados por comas

Question

Ok, he leído un par de libros en XML y escribí programas para escupirlos y lo que no. Pero esta es la pregunta. Tanto un archivo delimitado por comas como un archivo XML son "legibles por humanos". Pero en general, el archivo delimitado por comas es mucho más fácil para mis ojos que un archivo XML; las etiquetas suelen ocupar tanto o más espacio que los datos. Esto parece oscurecer lo que estoy leyendo y el formato puede tomar una página para contener la misma información que usted puede contener en una sola línea de texto en un archivo delimitado por comas. Y un archivo delimitado por comas es significativamente menos complejo de analizar. Entonces, la verdadera pregunta es ¿por qué XML? ¿Solo porque todos los chicos geniales lo están haciendo?

Answer 1

Estas no son las dos únicas opciones, también puede usar JSON o YAML que son mucho más livianas que xml.

En general, si tiene datos tabulares simples sin muchos caracteres especiales, CSV no es una mala opción. Para datos estructurados, considere usar uno de los otros 3.

Answer 2

Todo depende de lo que necesite hacer. Si necesita más complejidad en sus estructuras de datos que una simple estructura de fila "plana" puede dar. por ejemplo, datos jerárquicos, luego XML es una gran elección.

Answer 3

XML admite una representación compleja, estructurada y jerárquica de las cosas. Eso está lejos de lo que CSV puede almacenar trivialmente.

Piense en un gráfico de objeto complejo en un entorno orientado a objetos. Se puede serializar como un documento XML con bastante facilidad, pero CSV no puede manejar tal cosa.

Answer 4

CSV nunca fue realmente un estándar. Solo el mismo método rápido y sucio que un grupo de personas ideó de forma independiente. Por supuesto, algunas de estas personas eran más inteligentes que otras y se dieron cuenta de que necesitaban escapar de los personajes, pero otros no. Incluso MSSQL exporta CSV de forma incorrecta. Hay una forma correcta de hacer XML, así que si lo estás haciendo bien y la aplicación de alguien o lo que no lo acepte, tienes algo de influencia cuando dices "Eso no es mi culpa".

Answer 5

Xml se puede validar contra un contrato (esquema o DTD).

Answer 6

XML también tiene tecnologías complementarias que lo rodean: XMLDOM, XPath, XSLT, XSD, XML Esquemas

Answer 7

Ventajas

una serie de ventajas XML tiene más de CSV:

• Los datos jerárquicos organización
• Validación automática de datos (esquemas XML o DTD)
• Eas ily convertir formatos (utilizando XSL)
• fáciles de identificar estructura relacional
• se puede utilizar en combinación con XML-RPC
• Adecuado para persistencia de objetos (de clasificación)
• simplifica las comunicaciones de negocio a negocio
• tecnologías relacionadas votos (XPath, DOM)
• estrecha integración con los navegadores web modernos
• de extracción, transformación y carga (ETL)
• Al revés presentar compatibilidad de formatos (atributo de versión)
• Las firmas digitales

Depende completamente de dominio del problema y lo que está tratando de resolver.

Ejemplo

El último elemento es algo que mucha gente pierda la hora de escribir las páginas web. Considere la situación en la que tiene un gran almacén de datos de canciones. Las canciones tienen artistas, álbumes, ritmos por minuto, etc. Puede exportar los datos a XML, escribir una hoja de estilo simple para representar el XML como XHTML, luego señalar el navegador en la página XML. El navegador representará el XML como una página web.

No puede hacer eso con CSV.

Desventajas

Joel Spolsky tiene a great article sobre por qué XML es una mala elección como almacén de datos compleja: es lento. (A diferencia de una base de datos, que puede recuperar registros previos o siguientes con una única instrucción de CPU, atravesar registros en un documento XML es mucho más lento.) Posiblemente, esto podría considerarse un problema de optimización, resuelto por waiting 18 months. Por lo tanto:

• lento para analizar que otros formatos
• redundancia sintáctico puede restar valor a la legibilidad
hinchazón
• documento podría afectar los costos de almacenamiento
• No se puede modelar fácilmente superpuestas (no jerárquicas) estructuras de datos
• mal los formatos de archivo XML diseñados no son poco comunes (en mi experiencia; citación necesaria)

Pregunta relacionada

Véase también: Why Should I Use A Human Readable File Format.

Answer 8

Well XML es legible y editable por humanos. Puede ver un archivo XML y saber exactamente qué es. Un archivo CSV es legible por humanos, pero no se sabe realmente qué significa cada valor.

Por ejemplo, si almacenamos cuentas de usuario, ¿cuál prefieres?

<user> 
    <username>ryeguy</username> 
    <password>abc123</password> 
    <regdate>3-4-08</regdate> 
    <email>my@email.com</email> 
</user> 

O

ryeguy,abc123,3-4-08,my@email.com 

Por supuesto, esto es sólo un ejemplo, pero imagino que con 30 campos más o menos!

O peor aún, ¿y si hacemos subcampos?

<user> 
    <username>ryeguy</username> 
    <password>abc123</password> 
    <regdate>3-4-08</regdate> 
    <email>my@email.com</email> 
    <posts> 
     <post> 
      <id>34</id> 
      .... 
     </post> 
    </posts> 
</user> 

Eso sería un dolor en el culo para poner en un CSV. Pronto harías tu propio lenguaje de consulta.

Answer 9

El hecho de que XML sea legible por humanos no significa que se haya hecho con la idea de que los humanos lo lean (o incluso editen) directamente.

XML tiene un buen conjunto de propiedades que lo hacen una buena opción para muchos casos, en particular cuando tiene los recursos humanos para hacer frente a la carga adicional que tales propiedades inevitablemente traen: validación, estándar bien definido, mucho de herramientas, una arquitectura muy flexible, se asigna muy bien a un modelo de árbol, que es lo que utilizan muchos programas. Su legibilidad humana es un valor agregado que simplifica la depuración (intenta depurar un archivo binario ...), la inspección y pequeños cambios para casos triviales.

CSV, por otro lado es fácil, rápido y lineal, aunque existen muchos dialectos, y analizarlo bien es lejos de ser trivial (y con el problema añadido de que parece trivial!). Para la mayoría de las aplicaciones que involucran una tabla de datos, CSV es la elección perfecta.

En general, sin embargo, hay casos de representación de datos que puede resolver con XML pero que no puede resolver con CSV (por ejemplo, un árbol). Por otro lado, cualquier información que se pueda representar en CSV también se puede representar en XML, aunque no se garantiza (y de hecho también se verifica) que sea más eficiente (en términos de espacio, facilidad de análisis, etc.). Es una cuestión de "grados de libertad" de su formato. XML tiene un mayor valor de grado de libertad. CSV es más bajo La exageración detrás de XML también es relativa a este hecho.

No caiga víctima del síndrome de martillo: cuando tiene un martillo (XML), todo parece un clavo (algo que tiene que resolver con XML). La realidad es muy diferente y matizada. XML es genial, pero no es la respuesta a ningún problema.

Answer 10

Entre las razones por las que puede preferir XML sobre CSV (depende de la tarea en curso): * Casi todas las plataformas e idiomas tienen bibliotecas existentes para leer, escribir, analizar y manipular XML. * XML tiene reglas bien definidas para codificar todos los caracteres. CSV tiene ambigüedades, como cómo codificar las comas que forman parte de los datos. * XML admite una variedad de formas de datos (como jerárquicas) donde CSV es más útil cuando los datos se parecen a una tabla (filas y columnas).

Answer 11

XML describirá el contenido y también tiene un montón de bibliotecas compatibles en una variedad de idiomas ... pero puede ser inflado. Si el extremo receptor de la csv conoce el diseño y es tabular, no veo nada incorrecto en él.

Answer 12

Me gusta pensar en la principal distinción en este caso, ya que XML está basado en TREE, mientras que CSV está basado en TABLE.

Es decir, puede anidar, volver a anidar y omitir y, en general, hacer una compleja estructura de TREE en XML, mientras que solo puede hacer tablas 2D simples en CSV.