Existem (agora) potencialmente duas maneiras de realizar a compactação personalizada:
A partir do SQL Server 2016, existem funções internas para COMPRESS e DECOMPRESS . Essas funções usam o algoritmo GZip.
Use SQLCLR para implementar qualquer algoritmo que você escolher (como @Remus mencionado em sua resposta). Esta opção está disponível em versões anteriores ao SQL Server 2016, desde o SQL Server 2005.
O GZip é uma escolha fácil, pois está disponível no .NET e nas bibliotecas suportadas do .NET Framework (o código pode estar em um SAFE
Assembly). Ou, se você deseja o GZip, mas não deseja lidar com a codificação / implantação, pode usar o Util_GZip e o Util_GUnzip funções que estão disponíveis na versão gratuita do SQL # biblioteca SQLCLR (que eu sou o autor).
Se você decidir usar o GZip, seja você mesmo codificando ou usando o SQL #, lembre-se de que o algoritmo usado no .NET para fazer a compactação GZip mudou para melhor na versão 4.5 do Framework (consulte a seção "Comentários" no MSDN página para a classe GZipStream ). Isso significa:
- Se você estiver usando o SQL Server 2005, 2008 ou 2008 R2 - todos vinculados ao CLR v 2.0, que lida com as versões 2.0, 3.0 e 3.5 do Framework -, as alterações feitas no Framework versão 4.5 não terão efeito e, infelizmente, você estará preso ao O algoritmo original e ruim do .NET.
- Se você estiver usando o SQL Server 2012 ou mais recente (até agora 2014 e 2016) - todos vinculados ao CLR v 4.0, que lida com as versões 4.0, 4.5.x, 4.6 do Framework -, poderá usar o algoritmo melhor e mais novo. O único requisito é que você tenha atualizado o .NET Framework no servidor executando o SQL Server para a versão 4.5 ou mais recente.
No entanto, você não precisa usar o GZip e é livre para implementar qualquer algoritmo como esse.
OBSERVAÇÃO: todos os métodos mencionados acima são mais "soluções alternativas", em vez de substituições reais, mesmo que sejam tecnicamente "formas alternativas de compactar dados do NVARCHAR (MAX)". A diferença é que, com a compactação de dados incorporada - row
e page
- oferecida pelo SQL Server, a compactação é tratada nos bastidores e os dados ainda são utilizáveis, legíveis e indexáveis. Mas compactar qualquer dado em um VARBINARY
meio significa que você está economizando espaço, mas renunciando a algumas funcionalidades. É verdade que uma string de 20k não é indexável, mas ainda pode ser usada em umWHERE
, ou com quaisquer funções de cadeia. Para fazer qualquer coisa com um valor compactado personalizado, você precisará descompactá-lo rapidamente. Ao compactar arquivos binários (PDFs, JPEGs, etc), isso não é um problema, mas essa pergunta era específica dos NVARCHAR
dados.