Um antigo artigo da Microsoft diz para considerar o uso de ROWcompactação por padrão se você tiver muito espaço na CPU (ênfase minha).
Se a compactação de linha resultar em economia de espaço e o sistema puder acomodar um aumento de 10% no uso da CPU, todos os dados deverão ser compactados por linha
Hoje, temos ainda mais espaço de CPU do que tínhamos quando o artigo foi escrito. Homens sábios disseram que deveríamos considerar usar PAGEcompressão em todos os lugares, a menos que tenhamos uma razão convincente para não fazê-lo.
Tudo isso é um bom conselho e muitas vezes vejo sp_estimate_data_compression_savingsque concordam. No entanto, o que deve ser feito com tabelas minúsculas que são acessadas com frequência? Por exemplo, tenho algumas tabelas de dimensão extremamente pequenas. 100 linhas no máximo e pouquíssimas colunas. Como são tão pequenas, o benefício de economia de espaço de qualquer compactação é mínimo. Qual é considerada a melhor prática para aplicar ROWou PAGEcompactar tabelas tão minúsculas em caixas que têm uma quantidade enorme de espaço livre na CPU?
Para os propósitos desta questão, ignore columnstore. Estamos falando apenas de índices rowstore da velha escola em tabelas baseadas em disco.
Do ponto de vista do desempenho, não, você deve se concentrar em tabelas nas quais a economia de compactação ajuda a aproveitar melhor o hardware atribuído ao SQL Server.
Mas, de uma perspectiva de padrões e práticas, você deve compactar tudo, idealmente usando compactação de página. Ela define a cultura para a criação de índices em geral.
Se você realmente quisesse impor isso, poderia escrever um gatilho DDL que impedisse que índices fossem criados sem compactação.