Como se ha comentado se debe tener en cuenta que SQL Server no es un sistema nativo XML y que en el caso de XML hace una almacenamiento de los datos en forma binaria.
En esta segunda parte se comentarán la forma de actualización de los datos XML y algunas recomendaciones al momento de trabajar con datos XML en SQL Server.
Uno de los primeros temas a tener en cuenta es que deben evitarse los paths relativos y el uso de “//” para hacer una búsqueda en todo el documento, esto conspira fuertemente contra la eficiencia, especialmente cuando el documento XML es grande.
SQL Server también permite formas más avanzadas para procesar los datos XML. Una de éstas es mediante la función nodes(), la cual es imprescindible si necesitamos transformar un conjunto de nodos de un documento a una forma tabular (tabla).
Esta función se utiliza generalmente en conjunto con los operadores CROSSAPPLY y OUTER APPLY.
Por ejemplo si es necesario devolver un resultset, con columnas ID y Valor, que corresponden al id de cada nodo y a su contenido respectivamente. Para esto, se puede utilizar una consulta similar a la siguiente:
SELECT T1.C1.value(‘(@id)[1]‘,‘int’) AS ID,
T1.C1.value(‘.’,‘varchar(16)’) AS Valor
FROM @MiTabla
CROSS APPLY MiXML.nodes(‘/Datos/Empleado’) T1(C1)
WHEREIdentificador = 1
En este caso, el método nodes() permite crear instancias especiales XML (un registro por cada nodo que cumpla con el path especificado por el parámetro, conteniendo su súbarbol, insertado sobre una columna XML “C1” en una tabla ficticia “T1”). Esta tabla es combinada con el resto mediante un producto cartesiano (en este caso similar a un CROSS JOIN, o a un OUTER JOIN, cuando se utiliza OUTER APPLY). La columna C1 podrá luego ser utilizada como un campo cualquiera (XML) dentro del SELECT, al igual que en el ejemplo.
Actualizaciones
Al igual que para las consultas, las actualizaciones se realizan mediante una función especial modify(), que permite realizar cambios sobre un documento almacenado.
Cómo ejemplo básico, si se quisiera agregar un nuevo nodo Empleado al XML del ejemplo, se debería utilizar la siguiente consulta:
UPDATE @MiTabla SET MiXML.modify(‘insert
Alejandra
Moreno
Casado
as last into (/Datos[1])’)
WHERE Identificador = 1
Como resultado se insertará un nuevo elemento Empleado como último nodo dentro de la raíz Datos del XML de ejemplo.
<Datos>
<Empleadoid=“1“>
<Nombre>José CarlosNombre>
<Apellido>RomanoApellido>
<EstadoCivil>SolteroEstadoCivil>
Empleado>
<Empleadoid=“2“>
<Nombre>SusanaNombre>
<Apellido>ColmanApellido>
<EstadoCivil>CasadoEstadoCivil>
Empleado>
<Empleadoid=“3“>
<Nombre>AlejandraNombre>
<Apellido>MorenoApellido>
<EstadoCivil>CasadoEstadoCivil>
Empleado>
Datos>
Se debe tener en cuenta que todas las funciones presentadas requieren que el path que reciben sea un “string literal” (una cadena de texto plano), esto implica que debe ser un único parámetro y no puede ser el resultado de concatenaciones.
Esto puede resultar poco flexible, ya que ante una actualización o consulta, podríamos querer insertar o comprar datos no estáticos. Por esta razón se brindan las funciones sql:variable() y sql:column().
Volviendo al ejemplo si se quisiera insertar el valor almacenado en una variable se podría rescribir el UPDATE de la siguiente manera:
DECLARE @DatoAInsertar AS XML = ‘Alejandra
Moreno
Casado
UPDATE @MiTabla SET MiXML.modify(‘insert sql:variable(“@DatoAInsertar”) as last into (/Datos[1])’)
WHERE Identificador = 1
Consideraciones
Se debe tener en cuenta que un documento XML, una vez almacenado en una tabla con tipo de datos XML, será tratado como cualquier registro, por lo que si la instancia de un documento es muy grande (mas de 1GB por ejemplo), y además sufre gran cantidad de actualizaciones o bloqueos (se bloquea siempre el documento entero), la performance del sistema puede degradarse.
Cada vez que se realizada una consulta sobre un documento XML, éste debe ser parseado, por lo que a medida que el documento crece, la degradación de rendimiento también se hace evidente. Para esto se permite la indexación de los datos XML para colaborar en una mayor eficiencia, siempre hay que tener en cuenta el costo de mantener los índices ante las actualizaciones en los casos en que los documentos XML se actualizan en forma muy frecuente.
Conclusión
Como se a expuesto SQL Server brinda un conjunto amplio de funciones y operadores para manipular documentos XML, sin embargo siempre hay que tener en cuenta las características de las cargas transaccionales que se ejecutarán sobre los datos antes de optar por almacenarlos como XML dentro del sistema.
En general si el documento resultante es grande y necesita ser actualizado frecuentemente, deberíamos optar por una forma tradicional para almacenar la información.
Por otro lado, cuando el juego de datos resulta ser bastante estático y/o pequeño, podemos aprovechar las características del formato XML, como la estructura jerárquica o la auto-descriptividad.
Links de Referencia:
- Implementing XML in SQL Server: http://msdn.microsoft.com/en-us/library/ms189887.aspx
- XML Support in Microsoft SQL Server 2005: http://msdn.microsoft.com/en-us/library/ms345117(v=sql.90).aspx#sql2k5xml_topic2
- XML Storage in SQL Server: Strategies and Fallout: http://www.devx.com/xml/Article/26766
Autor: Fabián Gómez
Editado por : Marcos Ezquerra