length - Microsoft SQL Server 2005/2008: tipo de datos XML vs text/varchar
tipos de datos en sql server pdf (4)
¿Tiene más sentido (excepto la validación del lado del servidor XML / schema / dtd) almacenar XML en tipo XML en lugar de text / varchar / ntext? No estoy planeando hacer ninguna manipulación XML en el lado de la base de datos.
El propósito de mi investigación es disminuir el tamaño de la base de datos. ¿Puedo usar el tipo de datos XML para XML sin tipo para este propósito? ¿Cuáles son los pros y los contras?
Encontré un artículo relacionado con el tema , pero no estoy seguro de si las suposiciones / conclusiones de los autores son correctas.
Si almacena xml en una columna de tipo xml, los datos no se almacenarán como texto simple, como en el caso nvarchar, se almacenará en algún tipo de árbol de datos analizados, que a su vez será más pequeño que la versión xml sin analizar. Esto no solo disminuye el tamaño de la base de datos, sino que le brinda otras ventajas, como la validación, la manipulación fácil, etc. (aunque no esté utilizando ninguno de estos, están ahí para su uso futuro).
Por otro lado, el servidor tendrá que analizar los datos al momento de la inserción, lo que probablemente reducirá la velocidad de su base de datos; debe tomar una decisión de velocidad frente a tamaño.
Editar:
Personalmente, creo que los datos en la base de datos deben almacenarse como xml solo cuando tienen una estructura que es difícil de implementar en un modelo relacional, por ejemplo, diseños, descripciones de estilo, etc. Por lo general, eso significa que no habrá demasiados datos y la velocidad es no es un problema, así se agregaron características xml, como validación de datos y capacidad de manipulación (también, por último pero no menos importante, la capacidad de hacer clic en el valor en el estudio de gestión y ver xml formateado; ¡realmente me encanta esa función!), supere los costos.
No tengo experiencia directa en el almacenamiento de grandes cantidades de xml en la base de datos y no haría eso si tuviera la opción, ya que es casi siempre más lento que un modelo relacional, pero si ese fuera el caso, yo '' d recomendar el perfilado de ambas opciones y elegir entre el tamaño y la velocidad que mejor se adapte a sus necesidades.
Mi investigación rápida muestra que MS SQL 2005 (Express Edition)
Microsoft SQL Server 2005 - 9.00.3073.00 (Intel X86) 5 de agosto de 2008 12:31:12 Copyright (c) 1988-2005 Microsoft Corporation Express Edition en Windows NT 6.0 (Build 6000:)
almacene XML con una sobrecarga de aproximadamente el 70% (posible para un procesamiento / análisis más rápido).
Mis datos antes de la conversión: rows = 160320, reserved = 178576 KB, data = 178184 KB, index_size = 272 KB, sin usar = 120 KB
Mis datos después de la conversión: rows = 160320, reserved = 309702 KB, data = 307216 KB, index_size = 1672 KB, sin usar = 184 KB
Por lo tanto, no tiene sentido almacenar datos XML en el tipo de datos XML si no está planeando utilizar la tecnología XML en el lado de la base de datos.
Estoy usando xml extensivamente para comunicarme con dispositivos portátiles y estoy usando XQuery en la mayoría de mis procesos almacenados para recuperar solo los datos del XML que necesito. ¡Funciona EXCELENTE! Solo me preocupa el espacio de almacenamiento porque con solo cien mil registros más o menos, el tamaño de la base de datos es de 1 a 2 GB. Esperamos lanzar millones de registros almacenados para el registro y el uso del cliente ... por lo que será preocupante hasta que vea lo que realmente va a hacer en términos de uso del espacio.
Tiene sentido utilizar el tipo de datos XML para almacenar datos XML, ya que debe lidiar con UTF8 a UTF18 y viceversa en los servidores MS SQL.