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.<\/p>\n
En esta segunda parte se comentar\u00e1n la forma de actualizaci\u00f3n de los datos XML y algunas recomendaciones al momento de trabajar con datos XML en SQL Server.<\/p>\n
Uno de los primeros temas a tener en cuenta es que deben evitarse los paths relativos y el uso de \u201c\/\/\u201d para hacer una b\u00fasqueda en todo el documento, esto conspira fuertemente contra \u00a0la eficiencia, especialmente cuando el documento XML es grande.<\/p>\n
SQL Server tambi\u00e9n permite formas m\u00e1s avanzadas para procesar los datos XML. Una de \u00e9stas es mediante la funci\u00f3n nodes(), la cual es imprescindible si necesitamos transformar un conjunto de nodos de un documento a una forma tabular (tabla).<\/p>\n
Esta funci\u00f3n se utiliza generalmente en conjunto con los operadores CROSSAPPLY y OUTER APPLY<\/a>.<\/p>\n <\/p>\n 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:<\/p>\n SELECT T1.C1.value(\u2018(@id)[1]\u2018,\u2018int\u2019) AS ID,<\/p>\n T1.C1.value(\u2018.\u2019,\u2018varchar(16)\u2019) AS Valor<\/p>\n FROM @MiTabla<\/p>\n CROSS APPLY MiXML.nodes(\u2018\/Datos\/Empleado\u2019) T1(C1)<\/p>\n WHEREIdentificador = 1<\/p>\n En este caso, el m\u00e9todo nodes() permite crear instancias especiales XML (un registro por cada nodo que cumpla con el path especificado por el par\u00e1metro, conteniendo su s\u00fabarbol, insertado sobre una columna XML \u201cC1\u201d en una tabla ficticia \u201cT1\u201d). 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\u00e1 luego ser utilizada como un campo cualquiera (XML) dentro del SELECT, al igual que en el ejemplo.<\/p>\n Actualizaciones<\/b><\/p>\n Al igual que para las consultas, las actualizaciones se realizan mediante una funci\u00f3n especial modify(), que permite realizar cambios sobre un documento almacenado.<\/p>\n C\u00f3mo ejemplo b\u00e1sico, si se quisiera agregar un nuevo nodo Empleado al XML del ejemplo, se deber\u00eda utilizar la siguiente consulta:<\/p>\n UPDATE @MiTabla SET MiXML.modify(\u2018insert<\/p>\n Alejandra<\/p>\n Moreno<\/p>\n Casado<\/p>\n <\/p>\n as last into (\/Datos[1])\u2019)<\/p>\n WHERE Identificador = 1<\/p>\n Como resultado se insertar\u00e1 un nuevo elemento Empleado como \u00faltimo nodo dentro de la ra\u00edz Datos del XML de ejemplo.<\/p>\n <Datos><\/p>\n <Empleadoid=\u201c1\u201c><\/p>\n <Nombre>Jos\u00e9 CarlosNombre><\/p>\n <Apellido>RomanoApellido><\/p>\n <EstadoCivil>SolteroEstadoCivil><\/p>\n Empleado><\/p>\n <Empleadoid=\u201c2\u201c><\/p>\n <Nombre>SusanaNombre><\/p>\n <Apellido>ColmanApellido><\/p>\n <EstadoCivil>CasadoEstadoCivil><\/p>\n Empleado><\/p>\n <Empleadoid=\u201c3\u201c><\/p>\n <Nombre>AlejandraNombre><\/p>\n <Apellido>MorenoApellido><\/p>\n <EstadoCivil>CasadoEstadoCivil><\/p>\n Empleado><\/p>\n Datos><\/p>\n Se debe tener en cuenta que todas las funciones presentadas requieren que el path que reciben sea un \u201cstring literal\u201d (una cadena de texto plano), esto implica que debe ser un \u00fanico par\u00e1metro y no puede ser el resultado de concatenaciones.<\/p>\n Esto puede resultar poco flexible, ya que ante una actualizaci\u00f3n o consulta, podr\u00edamos querer insertar o comprar datos no est\u00e1ticos. Por esta raz\u00f3n se brindan las funciones sql:variable() y sql:column().<\/p>\n Volviendo al ejemplo si se quisiera insertar el valor almacenado en una variable se podr\u00eda rescribir el UPDATE de la siguiente manera:<\/p>\n DECLARE @DatoAInsertar AS XML = \u2018Alejandra<\/p>\n Moreno<\/p>\n Casado<\/p>\n <\/p>\n UPDATE @MiTabla SET MiXML.modify(\u2018insert sql:variable(\u201c@DatoAInsertar\u201d) as last into (\/Datos[1])\u2019)<\/p>\n WHERE Identificador = 1<\/p>\n Consideraciones<\/b><\/p>\n Se debe tener en cuenta que un documento XML, una vez almacenado en una tabla con tipo de datos XML, ser\u00e1 tratado como cualquier registro, por lo que si la instancia de un documento es muy grande (mas de 1GB por ejemplo), y adem\u00e1s sufre gran cantidad de actualizaciones o bloqueos (se bloquea siempre el documento entero), la performance del sistema puede degradarse.<\/p>\n Cada vez que se realizada una consulta sobre un documento XML, \u00e9ste debe ser parseado, por lo que a medida que el documento crece, la degradaci\u00f3n de rendimiento tambi\u00e9n se hace evidente. Para esto se permite la indexaci\u00f3n de los datos XML para colaborar en una mayor eficiencia, siempre hay que tener en cuenta el costo de mantener los \u00edndices ante las actualizaciones en los casos en que los documentos XML se actualizan en forma muy frecuente.<\/p>\n Conclusi\u00f3n<\/b><\/p>\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\u00edsticas de las cargas transaccionales que se ejecutar\u00e1n sobre los datos antes de optar por almacenarlos como XML dentro del sistema.<\/p>\n En general si el documento resultante es grande y necesita ser actualizado frecuentemente, deber\u00edamos optar por una forma tradicional para almacenar la informaci\u00f3n.<\/p>\n Por otro lado, cuando el juego de datos resulta ser bastante est\u00e1tico y\/o peque\u00f1o, podemos aprovechar las caracter\u00edsticas del formato XML, como la estructura jer\u00e1rquica o la auto-descriptividad.<\/p>\n Links de Referencia:<\/p>\n Autor:\u00a0Fabi\u00e1n G\u00f3mez<\/a><\/p>\n\n