¿Cuándo debo usar el tipo de datos XML en SQL Server?

Personalmente, nunca he usado el tipo de campo XML en SQL Server antes, y he hecho mucha programación de base de datos desde que agregaron esta función. Siempre me pareció que había una sobrecarga programática y de rendimiento al usar contenido XML en una base de datos de forma nativa. Honestamente pensé que era un truco, porque todos estaban en el tren XML en algún momento a principios de la década del 2000. "Oh, XML está de moda, así que vamos a agregarlo a SQL Server para que no veamos passe".

El mejor caso de negocios que puedo ver podría ser el registro de los mensajes de datos basados en XML que haya recibido, en los que quizás desee ver su estructura y sus datos, pero desea mantener la integridad del mensaje original por razones comerciales o legales. La sobrecarga puede ser demasiado grande para traducir el XML en una estructura de tabla, pero el uso de las capacidades XML en SQL Server podría reducir el costo de examinar los datos lo suficiente como para justificar su uso.

Probablemente haya docenas de otras razones por las que querría usarlo, pero francamente creo que debería considerar otros caminos hacia la felicidad antes de volverse loco con XML en SQL Server a menos que tenga razones comerciales muy específicas para hacerlo. Use un campo de varchar (max) o de texto si tiene más sentido.

Solo mi opinión, por supuesto :)

Solo he encontrado algunos escenarios en los que perseguiría activamente el uso del tipo de datos XML en SQL Server. Esto está fuera de mi cabeza, en orden de menos a más interesante:

• Almacenar / archivar las respuestas XML generadas por otras aplicaciones
  • Por ejemplo, usamos Application Integration Framework (AIF) para la comunicación entre una aplicación Silverlight personalizada y Dynamics AX. Almacenamos los mensajes entrantes y salientes en la base de datos para ayudar a resolver problemas de comunicación entre esas aplicaciones
  • Debido a que el tipo de campo es XML en lugar de un tipo de cadena genérico (es decir, VARCHAR), podemos usar XQuery para consultar específicamente los mensajes que coincidan con algunos criterios específicos. Esto sería mucho más difícil con una cadena simple como la coincidencia
• Almacenar en caché / persistir un mensaje de respuesta compuesto
  • Actualice el campo XML con un disparador o un código de aplicación, que imitaría una columna calculada
  • En lugar de regenerar constantemente una respuesta XML a una aplicación de llamada, incurriría en una sobrecarga solo cuando la fila se recargue, en lugar de en cada llamada
  • Esto funciona mejor cuando los SELECT son mucho más frecuentes que las ACTUALIZACIONES / INSERTOS, lo que suele ser cierto para la mayoría de las aplicaciones
• Almacenar múltiples valores en un solo campo
  • Una de las prácticas que he visto es el uso del tipo de datos XML para almacenar una colección de valores en un solo campo
  • Un beneficio es que no necesita diseñar un conjunto adicional de tablas para un simple almacén de clave / valor
  • Una desventaja de esto es que los datos no están completamente normalizados, lo que hace que la consulta sea menos obvia
  • Sin embargo, como se mencionó anteriormente, puede usar XQuery en ese campo XML para seleccionar filas que coincidan con los criterios de identificación, por lo tanto, puede neutralizar parcialmente el impacto de no estar completamente normalizado.

Todo lo dicho, el 99% del tiempo, no tengo absolutamente ninguna necesidad de un campo XML al diseñar un esquema.

Las pocas veces que he visto el tipo de datos XML en el servidor SQL se ha usado básicamente como un campo que se ha consultado como cualquier otro en la base de datos, lo que puede tener muy malas implicaciones de rendimiento si tiene una gran la cantidad de datos. Hay una razón por la que se llama servidor SQL y no servidor XML. :-) Las consultas que van en contra del XML simplemente no son tan rápidas como hacer una consulta de selección regular.

Podría ver que se utiliza para almacenar XML que no se consulta mucho, sin embargo, digamos que se guarda el documento XML completo en un tipo de datos XML, pero que los campos (claves) de búsqueda se almacenan por separado con el documento XML. De esa manera, puede consultar su información más rápidamente y extraer el documento XML cuando llegue al punto en el que desea ver el documento completo. De hecho, tuve que volver atrás y hacer esto con varias aplicaciones en las que las personas han tratado de usar el tipo de datos XML como un campo muy consultado y los datos han crecido hasta el punto en que la consulta se ha vuelto demasiado lenta.

He utilizado campos de tipo XML principalmente para fines de registro relacionados con los servicios web de ASMX o los servicios WCF. Puede guardar la solicitud o los mensajes de respuesta.

La mayoría de las veces, guarda el XML en la base de datos para fines de referencia, no para su actividad comercial habitual (no lo consulte cada 5 segundos desde el código). Si lo hace, determine los campos que normalmente consulta o usa la mayor parte del tiempo y cree columnas separadas para ellos. De esa manera, cuando esté guardando el XML en la base de datos, puede extraer estos campos y guardarlos en sus columnas correspondientes. Más adelante, al recuperarlos, no tendría que consultar el documento XML, solo puede utilizar las columnas que creó para este fin.

He hecho algo similar al serializar datos de objetos a XML para almacenamiento. Esto elimina la carga de tener tablas, columnas y relaciones en su lugar para almacenar datos de objetos complejos. Se puede ayudar al proceso mediante el uso de un esquema que cumpla con el resultado XML, y las tablas de la base de datos se pueden usar para la metainformación sobre los objetos en cuestión. En mi caso, ¡expandir el esquema de la base de datos para acomodar el diseño del objeto sería una gran tarea!

Estos son los escenarios que vienen a la mente inmediatamente cuando se considera qué condiciones deberían existir para permitir campos de XML en el servidor SQL:

• datos binarios codificados para el intercambio donde quieres ácido como control de el recurso
• Fragmentos de documentos que se reconstituirán en su totalidad utilizando dinámica. información
• los documentos o fragmentos enviados por el usuario que desea aislar y al menos sobre una base provisional mantener fuera del sistema de archivos directamente.