Uso de XML como almacenamiento de datos [cerrado]

Estaba pensando en el formato XML y la siguiente cita:

“XML no es una base de datos. Nunca fue destinado a ser una base de datos. Nunca será una base de datos. Las bases de datos relacionales son tecnología probada con más de 20 años de experiencia en implementación. Son productos sólidos, estables, útiles. No se van a ir XML es una tecnología muy útil para mover datos entre diferentes bases de datos o entre bases de datos y otros programas. Sin embargo, no es en sí una base de datos. No lo use como uno. "- XML efectivo: 50 formas específicas de mejorar su XML por Elliotte Rusty Harold (página 230, Parte 4, Artículo 41, 2º párrafo)

Esto parece realmente enfatizar que XML no debe usarse para el almacenamiento de datos y solo debe usarse para la interoperabilidad de programa a programa.

Personalmente, no estoy de acuerdo y el app.configarchivo .NET que se usa para almacenar la configuración de un programa es un ejemplo de almacenamiento de datos en un archivo XML. Sin embargo, para bases de datos en lugar de configuraciones, etc. No se debe usar XML.

Para desarrollar mi punto, usaré dos ejemplos:
A) Datos sobre clientes con campos que están todos en un nivel, es decir, hay una serie de campos relacionados con un cliente sin hijos
B) Datos sobre la configuración de una aplicación donde campos anidados y las propiedades tienen mucho sentido

Entonces mi pregunta es, ¿sigue siendo una declaración válida y ahora es aceptable almacenar datos usando XML?

EDITAR: He enviado un correo electrónico al autor de esa cita para pedirle su entrada / contexto adicional.

Esta cita no trata sobre el uso de XML como formato de almacenamiento en general (para lo cual está bien, según los requisitos), sino para el almacenamiento de tipo de base de datos .

Cuando las personas hablan de bases de datos, generalmente se refieren a sistemas de almacenamiento que almacenan grandes cantidades de datos, a menudo en el rango de gigabytes o terabytes. Una base de datos es potencialmente mucho más grande que la cantidad de RAM disponible en el servidor que la almacena. Dado que nadie necesita todos los datos en una base de datos a la vez, las bases de datos deben optimizarse para la recuperación rápida de subconjuntos selectivos de sus datos: para eso es la SELECTdeclaración, y las bases de datos relacionales, así como las soluciones NoSQL, optimizan su formato de almacenamiento interno rápidamente recuperación de tales subconjuntos.

XML, sin embargo, realmente no se ajusta a estos requisitos. Debido a su estructura de etiquetas anidadas, es imposible determinar en qué parte del archivo se almacena un determinado valor (en términos de desplazamiento de bytes en un archivo) sin recorrer todo el árbol de documentos, al menos hasta la coincidencia. Una base de datos relacional tiene índices, y buscar un valor en un índice, incluso con una implementación de búsqueda binaria primitiva, es una búsqueda única de O (log n), y luego llegar a los valores reales no es más que una búsqueda de archivos (p. Ej. fseek(data_file_handle, row_index * row_size)), que es O (1). En un archivo XML, la forma más eficiente es ejecutar un analizador SAX sobre su documento, haciendo un montón de lecturas y búsquedas antes de llegar a sus datos reales; difícilmente puede obtener esto mejor que O (n), a menos que use índices, pero luego, tendría que reconstruir todo el índice para cada inserción (ver más abajo).

Insertar es aún peor. Las bases de datos relacionales no garantizan el orden de las filas, lo que significa que solo pueden agregar nuevas filas o sobrescribir las filas marcadas como 'eliminadas'. Esto es extremadamente rápido: la base de datos puede mantener un grupo de ubicaciones de escritura; obtener una entrada del grupo es O (1) a menos que el grupo esté vacío; En el peor de los casos, el grupo está vacío y se debe crear una nueva página, pero esto también es O (1). Por el contrario, una base de datos basada en XML tendría que mover todo después del punto de inserción para hacer espacio; esto es O (n). Cuando entran en juego los índices, las cosas se vuelven aún más interesantes: los índices típicos de bases de datos relacionales pueden actualizarse con una complejidad relativamente baja, por ejemplo O (log n); pero si desea indexar sus archivos XML, cada inserción cambia potencialmente la ubicación en el disco de cada valor en el documento, por lo que debereconstruir todo el índice . Esto también se aplica a las actualizaciones, porque actualizar, por ejemplo, el contenido de texto de un elemento, puede cambiar su tamaño, lo que significa que el XML consecutivo debe cambiar. Una base de datos relacional no tiene que tocar el índice si actualiza una columna no indexada; una base de datos XML tendría que reconstruir el índice completo para cada actualización que cambie el tamaño del nodo XML actualizado.

Esos son los inconvenientes más importantes, pero hay más. XML es muy detallado, lo cual es bueno para la comunicación de servidor a servidor, ya que agrega seguridad (el servidor receptor puede realizar todo tipo de verificaciones de integridad en el XML, y si algo salió mal en la transferencia, es poco probable que el documento valide ) Sin embargo, para el almacenamiento masivo, esto es mortal: no es raro tener una sobrecarga del 100% o más para los datos XML (no es raro ver relaciones de sobrecarga en el rango del 1000% para cosas como mensajes SOAP), mientras que el almacenamiento de base de datos relacional típico los esquemas solo tienen una sobrecarga constante para los metadatos de la tabla, más un pequeño bit por fila; La mayor parte de la sobrecarga en las bases de datos relacionales proviene de anchos de columna fijos. Si tiene un terabyte de datos, una sobrecarga del 500% es simplemente inaceptable, por muchas razones.

XML es pésimo para el almacenamiento de datos. Primero, es muy detallado. Los datos almacenados en un archivo XML ocuparán mucho más espacio en disco que los mismos datos almacenados en cualquier sistema de base de datos razonable. En un registro XML, el nombre de un campo en particular se almacenará dos veces, junto con la representación de cadena de los datos. Entonces, por ejemplo, para almacenar un solo integar en un campo llamado "foobar", terminas con esta cadena de 19 bytes:

<foobar>42</foobar>

Por otro lado, una base de datos real almacenará esto como un único valor integar, tomando 4 bytes. Si su base de datos es pequeña, eso no significa mucho, pero si tiene 10,000 registros, eso es un problema.

En segundo lugar, se debe analizar un XML del texto cada vez que se lee el archivo. Para el campo anterior, una base de datos real simplemente lee los datos binarios en la memoria desde el desplazamiento en el que sabe que almacenó el campo "foobar". Si el archivo se almacena como XML, debe leer el campo "foobar", analizar ese texto , determine qué campo es, luego analice la cadena "42" y conviértala en el binario 42.

Por lo tanto, las penalizaciones de rendimiento por usar XML son enormes. Los beneficios de XML son que es algo legible para los humanos y que permite una fácil transferencia de datos entre sistemas completamente separados. Ninguna de esas ventajas se aplica a una base de datos local.

La única excepción son los archivos de configuración, que generalmente son pequeños y, por lo general, deben ser editables por humanos.

Una base de datos XML será absolutamente más grande y lenta que cualquier sistema SQL razonable. A menos que pueda encontrar una ventaja de contrapeso en la legibilidad o interoperabilidad humana, simplemente no tiene sentido usarlo para el almacenamiento de datos.

XML es viable según el contexto. Si sus datos son bastante estáticos y no cambian mucho (datos de muestra, por ejemplo), sí XML es un buen uso.

Los ajustes de configuración, los datos de muestra (incluso si son millones de filas, pero rara vez cambian), son buenos usos de XML.

Las lecturas / escrituras del disco duro son caras, mucho más que acceder a los datos desde una pila Oracle / SQL.

Esto parece realmente enfatizar que XML no debe usarse para el almacenamiento de datos y solo debe usarse para la interoperabilidad de programa a programa.

Tu premisa es defectuosa.

El párrafo que cita en realidad dice que XML no es un reemplazo para una base de datos , no que no debería usarse para el almacenamiento de datos .

Está claro que un archivo de configuración no es lo mismo que una base de datos, por lo que se pueden (y deberían) utilizar diferentes tecnologías.

Corrígeme si me equivoco, pero parece que tienes más experiencia con los lenguajes de marcado que las bases de datos. Si tuviera un poco de experiencia con las bases de datos, se daría cuenta para qué dominios son adecuadas las dos tecnologías diferentes.

Esto es realmente subjetivo. Esa cita es, como, la opinión de alguien, hombre.

Honestamente, creo que XML es una alternativa viable a una base de datos, ya que tiene múltiples ventajas sobre un RDMS, incluida una baja sobrecarga, lo que equivale a un almacenamiento más barato (especialmente cuando se utiliza un servicio de alojamiento que cobra por las bases de datos por separado).

Eche un vistazo a dasBlog y BlogEngine . Ambas aplicaciones usan xml para almacenamiento de forma predeterminada.

Eso dicho No es un RDMS, y si tiene una alta volatilidad (muchas actualizaciones, inserciones o eliminaciones) en sus datos o requiere alta disponibilidad, use una base de datos. XML está bien para almacenar cosas pequeñas como datos de configuración y datos de baja volatilidad.

mi pregunta es, ¿sigue siendo una declaración válida y ahora es aceptable almacenar datos usando XML?

Veo su punto en su ejemplo sobre los archivos de configuración .NET. Sin embargo, cualquier otro formato de archivo podría haber sido utilizado. De hecho, en los viejos tiempos, tales configuraciones solían almacenarse en archivos de texto regulares llamados archivos INI.

Veo que la declaración que ha presentado en gris es válida y correcta si define una base de datos como un sistema de software.

La definición de XML en XML-Definition establece que "(XML) es un lenguaje de marcado que define un conjunto de reglas para codificar documentos en un formato que sea legible por humanos y por máquina".

Esta definición se centra en la legibilidad y el lenguaje más que en los mecanismos para administrar los datos.

En comparación con un RDBMS, XML no proporciona medios para insertar y eliminar al azar filas en un archivo XML. Por ejemplo, si tiene 1000000 filas y desea eliminar filas al azar, incluso en un solo entorno de usuario, el archivo basado en XML no sería una buena opción para una base de datos. Además, XML no proporciona ningún mecanismo nativo para bloquear datos. De hecho, dado que XML no es un software, todas las propiedades de ACID (atomicidad, consistencia, aislamiento, durabilidad) que garantizan que las transacciones de la base de datos se procesen de manera confiable en un entorno compartido se dejan al desarrollador para construir (con la excepción de Durabilidad). XML no tiene una especificación robusta para manejar la integridad de los datos a través de archivos XML, y mucho menos de diferentes servidores (por ejemplo, el archivo xml del cliente y el archivo xml de pedidos, sin FK para hacer cumplir la integridad).

Lo anterior no es una enumeración de lo que carece de XML, sino que podría servir como una justificación rápida de la afirmación de que XML no es un software de base de datos .

XML nunca tuvo la intención de ser una base de datos o reemplazarla.

XML se define principalmente para documentos web que allows for the creation of customized tags for individual information fields., sin embargo, nunca lograría una gestión de datos centralizada relacional con él.

¿Por qué querrías usar XML para almacenar datos en primer lugar? Quiero decir, es un idioma después de todo ...

Si bien se podría argumentar que es un formato flexible y fácil de entender, eso solo se aplica cuando tiene que editar manualmente los archivos. Cuando realmente interactúa con la base de datos con una interfaz común (recuperar datos X que cumple con los requisitos Y y Z, almacenar / actualizar datos X, ...) esas ventajas se anulan.

Respuesta corta: depende.

Respuesta larga: desde mi punto de vista, esto depende en gran medida de la cantidad de datos que desea almacenar. Por ejemplo, si tiene un par de objetos en su aplicación durante el tiempo de ejecución y desea almacenarlos después de ejecutar la herramienta, un archivo XML está perfectamente bien. Sin embargo, si su tienda web tiene 5000 clientes y aún más pedidos, una base de datos sería un almacenamiento de datos más apropiado.

Además, creo que almacenar la configuración en una base de datos y no en un archivo como app.config en la mayoría de los casos no es muy útil, pero no creo que este ejemplo pruebe que la cita sea incorrecta.

XML es una excelente opción para la configuración. Los archivos XML no solo son fáciles de analizar / resaltar en un IDE, sino que también son muy fáciles de editar para los no programadores. Los encuentro increíblemente útiles en escenarios de desarrollo web donde los diseñadores y administradores de contenido están realizando tareas de mantenimiento.

Normalmente, XML no debe utilizarse como fuente de datos primaria para ninguna aplicación no trivial. La sobrecarga de serialización / deserialización solo pide una solución diferente.

El término base de datos puede referirse solo a los datos sin procesar o también al sistema de administración de la base de datos. Esta definición hace una gran diferencia en todo el argumento.

Si usamos la definición RDBMS, XML tiene muy poco en ese sentido. Obtiene muy poco en términos de garantías de ACID (tendría que escribir su propio código para cumplirlas). Si necesita esos (y la mayoría de los sistemas transaccionales los necesitan), ya está en un gran problema. Podría dar una lista de cientos de características que se dan por sentado con RDBMS, que tendría que reinventar y reimplementar. Piense en modelos de seguridad, replicación, copias de seguridad, solo por nombrar algunos básicos.

En el sentido anterior, no, XML no es una base de datos, y no debe intentar usarlo como tal.

Si utilizamos la definición de "datos en bruto", XML obtiene mejores resultados, pero aún así no es tan bueno. Sin embargo, como otros han señalado, es muy detallado en general, por lo general carece de codificación binaria y tiene etiquetas duplicadas, etc. Estas son compensaciones hechas para que XML pueda ser legible para los humanos; básicamente, la eficiencia es el enemigo de este requisito. . XML tampoco es un ajuste particularmente bueno incluso para las situaciones más simples en las que inserta registros continuamente. Suponiendo que desea que su archivo XML sea válido, necesita una sola etiqueta de cierre, lo que significa que agregar un registro significa que necesita cambiar las etiquetas al final. Esto es bastante costoso (¿cómo sabemos dónde comienza esa etiqueta? ¿Qué pasa si hay varias "tablas", simplemente movemos hacia arriba todo el archivo?), Y si desea solucionarlo, usted "

Hay situaciones en las que XML es apropiado: los archivos de configuración son un gran ejemplo, porque suelen ser pequeños y la legibilidad humana es una característica excelente. Tener una base de datos solo para un archivo de configuración puede ser excesivo.

Las bases de datos, por otro lado, son excelentes cuando tienes miles (o millones / miles de millones) de registros y muchos usuarios los actualizan simultáneamente. Entonces, sí, XML no es una base de datos, y no debe usarlo como tal. Su ejemplo es una de esas situaciones en las que no necesitaba una base de datos en primer lugar, y XML es la mejor opción.

La forma en que lo veo es esta: si usa XML como DB (por ejemplo, como un almacén de respaldo para un sistema transaccional), terminará reinventando y reescribiendo un RDBMS . Esa es una forma realmente pobre de gastar su tiempo y energía. Creo que esto es lo que decía esa cita también.

Estoy de acuerdo en que no es una base de datos relacional. Creo que el autor simplemente está diciendo en la cita que no lo use como uno.

Dicho esto, aunque puede que necesite o no uno. Si realmente no necesita hacer muchas consultas sobre los datos, y solo tiene la intención de almacenarlos y luego buscarlos más tarde en función de algunos criterios de consulta limitados, entonces necesita almacenamiento y recuperación de DOCUMENTOS XML, no una base de datos relacional.

Hay muchas aplicaciones que simplemente necesitan almacenar un documento con datos para recuperarlo en su totalidad más tarde. Si este es el caso, entonces es inútil crear un esquema basado en SQL, analizar el XML y luego serializarlo en la base de datos solo para hacer lo contrario más adelante. Hay una gran sobrecarga de código potencialmente involucrada en hacer eso. Sin embargo, hay menos si lo haces bien.

Puede usar herramientas ORM como Hibernate y herramientas como Apache Axis para autogenerar prácticamente todo el código que necesitaría para construir un servicio que solo maneja operaciones CRU simples. Tendría que incluirlo en la autenticación, por supuesto, y posiblemente desee segregar los datos en función del usuario, el nivel de acceso, etc. Incluso puede limitar las operaciones que un usuario determinado puede realizar a través del servicio SOAP para ejemplo.

En este sentido, estás haciendo más como gestión de contenido que cualquier otra cosa.