Los RDBMS modernos tienen soporte para tipos de columnas XML y funcionalidad para manejar XML en procedimientos almacenados. Históricamente siempre habría mapeado datos jerárquicos (ya sea de objetos OO o XML) a tablas relacionales. Dado el amplio soporte de bases de datos para XML, ¿debería cambiar mi forma de actuar?¿Por qué alguna vez elegiría almacenar y manipular XML en una base de datos relacional?
Puede almacenar XML generado por el usuario allí.
Si un sitio web como stackoverflow utilizara algún tipo de marcado XML en lugar de marcar, podría almacenar las preguntas/respuestas como XML en la base de datos. Puede que intente analizar el XML generado por el usuario buscando etiquetas de propiedad.
Digamos que tiene una entidad que tiene atributos. Puede almacenar todos esos atributos en XML en lugar de crear una tabla de atributos separada. El XML sería más flexible.
Si no ve la necesidad, ¡entonces no la cambie!
A veces tiene que conservar los datos que no tienen una estructura conocida, o su estructura es muy volátil. En esos casos, en lugar de crear una tabla, simplemente guarde el XML en su tabla existente
Sin embargo, si es XML, ¿no esperaría que tuviera una estructura fija, o al menos bien definida? –
No, ¿qué significa la X en XML? Si quieres arreglarlo, simplemente usarías un conjunto de tablas y campos. Bien definido, está bien, pero la definición puede cambiar con más frecuencia de lo que puede hacer a través de los cambios en el esquema de la base de datos. – AnthonyWJones
La flexibilidad es una razón.
Si la estructura de sus datos puede variar, entonces aún puede mantener una tabla RDBMS común, junto con las consultas, etc. que lo complementan con los datos algo estructurados.
Si necesita agregar un campo en algún momento, puede hacerlo sin cambiar la estructura de su tabla RDMS, y así no interrumpir las consultas de los demás.
No estoy seguro de que sea así de simple. Si se escriben consultas para extraer el XML, entonces cambiar su estructura aún podría romper el código que procesa los resultados. –
Puede procesar datos XML directamente en el servidor SQL. P.ej. puede aplicar expresiones XPath y simplemente enviar el conjunto de resultados filtrados al cliente. Las características del servidor SQL pueden desarrollar capacidades de procesamiento XML más adelante.
las características anteriores existen de MS SQL Server 2000 o 2005.
¿Pero solo procesaría XML en el servidor si estuviera preocupado por la sobrecarga de transferir demasiado a la aplicación de servidor/cliente? – tpower
No tengo XP de la vida real al respecto. Puedo recomendar medir o encontrar datos sobre el rendimiento de la potencia de procesamiento XML de su servidor. Leí en un libro de MCTS que puedes usar el procesamiento XML en MSSQL y está recomendado. Consulte TechNet o MSDN para obtener más detalles. – artur02
Procesar XPath en SQL Server es MUY lento. –
Por ejemplo, se obtiene documentos XML desde algún otro sistema, con estructura muy rica o compleja que desea almacenar; pero solo necesita algunas consultas bien definidas para recuperar esos datos. En ese caso, simplemente analice los datos que necesita para generar algunos índices, y almacene toda la estructura XML en un solo campo.
Para hacer eso, no necesita mucho soporte XML específico en el motor de DB, pero aún así ayuda a mantener las consultas expresivas.
Además de eso, supongo que algunos DMBS con buena compatibilidad con XML podrían permitirle simplemente almacenar el documento XML, quizás sin especificar cómo indexarlo. Simplemente usa XQuery y espera que de alguna manera se optimice según sus necesidades.
Tengo un buen ejemplo de la vida real. Uno de mis clientes recibe un archivo XML de sus proveedores muy a menudo con algunos datos importantes. Está profundamente anidado. Necesitan compararlo con el archivo XML anterior para ver qué ha cambiado. Sin soporte de XML en la base de datos, tuve que crear una herramienta que itera a través de nodos XML y busca coincidencias en las tablas de la base de datos relacional. Podría usar alguna herramienta de comparación XML-XML, pero algunas de las comprobaciones se relacionan con otros datos que no provienen del archivo XML y necesito unir todo eso. De acuerdo, todo esto no es gran cosa, pero aún así, con las bases de datos XML obtienes esa funcionalidad lista para usar.
Aquí hay un ejemplo del mundo real de un sistema en el que trabajo. Tenemos un sistema central y creamos un código específico para el cliente en Java. Se puede llamar a una clase diferente dependiendo de qué cliente esté realizando transacciones. A veces, este código personalizado necesita almacenar algo y lo colocamos en una columna XML en la tabla correspondiente. Esto nos salva de modelar todo bajo el sol. Agregar un nuevo cliente generalmente solo significa escribir e instalar el código de Java.
El inconveniente es que los informes, las consultas y las actualizaciones son más difíciles en la columna XML. No hay ninguna de las buenas características de base de datos habituales como restricciones de verificación, etc.
No he tenido la necesidad de almacenar XML hasta ahora, pero con frecuencia uso la capacidad de devolver XML desde un procedimiento almacenado. Hace que algunas cosas sean muy útiles, principalmente informes. Puedo ejecutar un SP para generar el informe, devolver los resultados en XML y luego usar XSLT para mostrar el resultado en el sitio muy fácilmente.
He hecho esto también, pero escasea mal. Algunos informes que hemos corrido a miles de filas. El XML tenía que estar en la memoria a la vez (primero en la base de datos, luego en el cliente) frente a un conjunto de registros cruzado y consumido. –
Uso el tipo de columna XML para esconder una copia de todos los mensajes críticos para la empresa que recibimos de un servicio de terceros. Es muy útil por algunas razones.
1) En caso de corrupción de datos, podemos rastrear para ver qué datos entraron cuando y en qué formato.
2) El trabajo de desarrollo futuro en sistemas puede basarse en datos reales de la tabla de registro; simplemente deserializar y usar los datos como si provinieran de una llamada al servicio 3p
3) Asegura que los chicos de la infraestructura estén ocupados asignando el disco espacio para el servidor de base de datos. ;)
esto parece ser una de las mejores razones para usarlo. no hay garantías cuando se trata con terceros. :-PAG – user420667
La única razón por la que alguna vez lo volvería a utilizar es cuando para la flexibilidad de extensibilidad &.
La sobrecarga de xml (xpath) y el mantenimiento (espacios de nombres) realmente no valen la pena si se puede evitar. Anteriormente almacenamos grandes cantidades de datos en xml y usamos funciones escalares para recuperarlos, pero es demasiado lento y causa dolores de cabeza inmensos cuando cambia la estructura xml o el espacio de nombres.
Pero la flexibilidad es fantástica. Puede agregar nuevas propiedades cuando lo desee, puede tener datos específicos del proyecto/cliente/trabajo allí que no requieren columnas adecuadas. El XML no tiene que estar en una estructura estática; simplemente necesita una fábrica que pueda engendrar instancias para tratar con los diferentes XML (que deberían estar relacionados con un proyecto/cliente/trabajo).
Al agregar una tabla nueva a un sistema existente, especialmente una que tiene una gran cantidad de datos existentes y no se puede modificar fácilmente, agregaré una columna XML. En el futuro, si alguna vez necesito agregar otra columna a esa tabla, simplemente puedo utilizar la columna XML en lugar de sentirme frustrado y tener que trabajar mucho más.
En resumen, no comienzas colocando propiedades esenciales en XML. Pero debe agregar XML cuando sepa que su tabla podría necesitar ser extendida, precisamente porque le da la opción de extenderla.
¿Puedes elaborar? –
Esto también se puede hacer con un campo LONGVARCHAR. – Horcrux7
Pero puede poner una restricción en un varchar para decir que debe ser XML válido. – tpower