Solución:
Tanto la compresión de página como la de fila no comprimen BLOB.
Debido a su tamaño, los tipos de datos de gran valor a veces se almacenan por separado de los datos de fila normales en páginas de propósito especial. La compresión de datos no está disponible para los datos que se almacenan por separado.
Si desea comprimir BLOB, debe almacenarlos como VARBINARY(MAX) y aplique el algoritmo de compresión de flujo de su elección. Por ejemplo GZipStream. Hay muchos ejemplos de cómo hacer esto, solo busque GZipStream y SQLCLR.
Hay (ahora) potencialmente dos formas de lograr una compresión personalizada:
-
A partir de SQL Server 2016, hay funciones integradas para COMPRESS y DECOMPRESS. Estas funciones utilizan el algoritmo GZip.
-
Use SQLCLR para implementar cualquier algoritmo que elija (como @Remus mencionó en su respuesta). Esta opción está disponible en versiones anteriores a SQL Server 2016, desde SQL Server 2005.
GZip es una opción fácil porque está disponible dentro de .NET y en las bibliotecas de .NET Framework compatibles (el código puede estar en un
SAFEMontaje). O, si desea GZip pero no quiere ocuparse de codificarlo / implementarlo, puede usar el Util_GZip y Util_GUnzip funciones que están disponibles en la versión gratuita de la biblioteca SQL # SQLCLR (de la que soy autor).Si decide usar GZip, ya sea que lo codifique usted mismo o use SQL #, tenga en cuenta que el algoritmo utilizado en .NET para realizar la compresión GZip cambió en la versión 4.5 de Framework para mejor (consulte la sección “Comentarios” en MSDN página para la clase GZipStream). Esto significa:
- Si está utilizando SQL Server 2005, 2008 o 2008 R2, todos vinculados a CLR v 2.0, que maneja las versiones 2.0, 3.0 y 3.5 de Framework, entonces el cambio realizado en la versión 4.5 de Framework no tiene ningún efecto y, lamentablemente, está atascado con El algoritmo original y apestoso de .NET.
- Si está utilizando SQL Server 2012 o más reciente (hasta ahora 2014 y 2016), todos vinculados a CLR v 4.0 que maneja las versiones 4.0, 4.5.x, 4.6 de Framework, entonces puede usar el algoritmo más nuevo y mejor. El único requisito es que haya actualizado .NET Framework en el servidor que ejecuta SQL Server a la versión 4.5 o posterior.
Sin embargo, no tiene que usar GZip y puede implementar cualquier algoritmo como.
TENGA EN CUENTA: todos los métodos mencionados anteriormente son más bien “soluciones provisionales” en lugar de ser reemplazos reales, aunque técnicamente son “formas alternativas de comprimir datos NVARCHAR (MAX)”. La diferencia es que con la compresión de datos incorporada: row y page – ofrecido por SQL Server, la compresión se maneja detrás de escena y los datos aún se pueden usar, leer e indexar. Pero comprimir cualquier dato en un VARBINARY significa que está ahorrando espacio, pero renunciando a algunas funciones. Es cierto que una cadena de 20k no es indexable de todos modos, pero aún se puede usar en un WHERE cláusula, o con cualquier función de cadena. Para hacer cualquier cosa con un valor comprimido personalizado, necesitaría descomprimirlo sobre la marcha. Al comprimir archivos binarios (PDF, JPEG, etc.), esto no es un problema, pero esta pregunta era específica de NVARCHAR datos.