para almacenar datos XML como XML o en tablas normalizadas

Question

(Este mensaje está solicitando experiencias personales sobre el almacenamiento XML;. Por favor comparte lo que sabes :-))

Estoy trabajando en una aplicación de servicio que se comunica con un servicio externo usando XML. Estoy planeando usar SQL Server 2008 para almacenar el XML que se recibe y se envía al servicio externo. Estoy explorando mis opciones para almacenar el XML en la base de datos. Las tres opciones que he identificado son:

1. tienda el XML en una columna XML tipo de datos
2. Crear tablas para almacenar las diversas relaciones de padres e hijos representados en el XML.
3. Un híbrido de los dos enfoques anteriores donde el XML original se almacena en una columna de tipo de datos XML pero varios campos del XML se dividen en sus propias columnas para simplificar las consultas y la indexación.

Estoy buscando algún consejo, basado en su experiencia personal, con el almacenamiento y la recuperación de datos XML en SQL Server.

Algunos antecedentes: he utilizado un equivalente 'xsd.exe' llamado XsdObjectgenerator para crear clases .net basadas en los esquemas XML. Cuando el servicio recibe el archivo XML, se deserializa en una instancia de la clase .net. Esta instancia se usa para realizar las operaciones del servicio. Mi plan original era utilizar la opción n. ° 1 anterior para almacenar el XML. Si tuviera que actualizar o informar sobre los datos, simplemente deserializaría el registro db en una de mis clases .net.

Aunque este enfoque funciona y hace que trabajar con xml sea muy simple, me preocupa que a medida que aumente el volumen de datos, disminuirá el rendimiento de la consulta de registros de tipos de datos XML. Es por eso que he explorado las opciones 2. & 3. arriba.

Además de almacenar el XML, se consultará el XML para su uso en ambos informes y en una aplicación web por separado. Los registros de db serán consultados, ordenados, filtrados, agrupados, resumidos y posiblemente actualizados por los usuarios finales.

Answer 1

Supongo que depende de lo que quieras hacer con tu XML en tu base de datos.

Si solo lo está almacenando y posiblemente recuperándolo más tarde en su totalidad y enviándolo nuevamente, entonces definitivamente usaría el tipo de datos XML; no tiene sentido dividirlo en pedazos.

Si, sin embargo, tiene que trabajar principalmente con los contenidos del archivo XML, y posiblemente también manipular y cambiar ese contenido, puede ser aconsejable crear tablas con columnas que coincidan con su contenido XML y triturarlo cuando lo guarde , úselo, y cuando sea necesario, vuelva a montarlo de las piezas relacionales usando algo como SELECT (columns) FROM dbo.Table FOR XML.....

Hay una sobrecarga involucrada en la trituración y el reensamblaje, por lo que debe preguntarse si eso vale la pena. Pero también hay una sobrecarga involucrada si necesita manipular demasiado la columna XML.

Si solo necesita acceso de solo lectura a algunos atributos en su XML, he llegado a apreciar la capacidad de incluirlos en un UDF y mostrarlo como una columna calculada en su tabla. De esta forma, puede seleccionar fácilmente algo de su tabla, basado en valores que están almacenados en algún lugar dentro de su XML, ¡bastante útil! Pero no abuse de este enfoque, funciona bien para 2, 3 atributos, pero si necesita acceder a su XML una y otra vez (y la mayoría o la totalidad), entonces sería mejor que lo triture en piezas relacionales para comenzar. .

Answer 2

Sin dejar de explorar soluciones, un colega transmitió las siguientes enlaces aplicables:

• SQL Server Performance with Key/Pair Table vs XML Field and XPath
• XML Support in Microsoft SQL Server 2005

algunas conclusiones preliminares de estos artículos y otras investigaciones:

• Mientras se trabaja con xml dat atype en SQL Server es flexible, la consulta de grandes volúmenes de datos será lenta, ya que básicamente se está consultando un tipo de datos blob.
• Si bien puede crear índices en columnas de tipo xml en Servidor SQL, el índice está en la columna completa y no en un elemento o atributo en particular, por lo que los índices no son tan efectivos como un índice en una columna db no xml.
• Almacenamiento del xml en forma cruda en un campo de tipo de datos XML al mismo tiempo mantener una versión analizada de los datos en cualquiera de las tablas relacionales o mesa plana desnormalizado (s) para consultas e informes está empezando a surgir como el la solución más flexible . El xml se puede "triturar" en las tablas de consulta ya sea en el tiempo de ejecución o después del hecho por un servicio 0 hilo .

Me burlaré de cada solución con los datos de prueba y realizaré algunos benchmarking. Publicaré los resultados aquí una vez que estén disponibles.

Answer 3

Algunos trabajos atrás (SQL 2000), almacenamos XML como datos TEXT, y nuestras bases de datos se hincharon significativamente, no tanto con los datos como con las etiquetas utilizadas para identificarlo. Hice algunas pruebas, y pkzip (dije que fue varios trabajos atrás) redujo todos los datos al 3% de su tamaño original.

Consejo n. ° 1: Identifique durante cuánto tiempo debe almacenar los datos y, si es posible, archive los datos viejos.

Consejo # 2: Si está utilizando SQL 2008, mire las opciones de compresión de datos para las columnas XML.

(no podría ser relevante si sus XMLs son cortos, pero la nuestra estaban todos en el kbs y 10kbs.)