Um de nossos clientes usa para algumas colunas o tipo de dados DECIMAL(18,0)em seu banco de dados SQL Server 2008R2. Como as colunas crescem muito lentamente, ele propôs recentemente alterar o tipo de dados DECIMAL(5,0)para recuperar algum armazenamento.
De acordo com a biblioteca MSDN , o espaço de armazenamento do tipo de DECIMAL(5,0)dados é, assim como o DECIMAL(9,0)tipo de dados, de 5 bytes. INTé 1 byte menor, mas pode armazenar tudo no intervalo de -2^31 a 2^31 em vez de -99.999 a 99.999 que DECIMAL(5,0)pode armazenar. Mesmo o maior DECIMALque cabe em 5 bytes ( DECIMAL(9,0)) pode armazenar apenas números inteiros no intervalo -999.999.999 a 999.999.999 (que é menos da metade do intervalo INToferecido em 4 bytes).
Posso pensar em dois "benefícios" de usar DECIMALover INT:
- A capacidade de adicionar escala posteriormente, sem usar mais espaço de armazenamento
- A capacidade de escalar a precisão até 38 dígitos, sem alterar o tipo de dados
mas estes não são benefícios reais na minha opinião:
- Adicionar escala a números inteiros só faz sentido em poucos casos (na maioria dos casos em que a escala faz diferença, ela também pode ser adicionada de antemão)
- O SQL Server vê cada combinação de precisão/escala como um tipo de dados diferente, portanto, o tipo de dados não é deixado sozinho ao aumentar a precisão ou a escala.
Isso me faz pensar: qual é o benefício adicional de um DECIMAL(5,0)tipo de dados para números inteiros?
Concordo que não há benefícios reais em termos de espaço de armazenamento , desde que você esteja comparando DECIMAL(9, 0) vs INT ou DECIMAL(18, 0) vs BIGINT. (Dentro de um único byte.)
Em termos de processamento, como @Andriy diz, o DECIMAL se dividirá naturalmente em um tipo que não perca a parte fracionária, se isso for importante para você.
Por outro lado, trabalhar com tipos INT nativos é muito mais rápido do ponto de vista numérico se você estiver fazendo muitas SUM()s ou comparações (como pesquisar os valores), pois eles são canalizados com mais eficiência pela CPU. Uma comparação int é dois opcodes de montagem (MOV, CMP), mas qualquer comparação decimal será muito, muito mais.
Parece que não haverá benefícios em termos de espaço de armazenamento.
Se o seu cliente estiver preocupado com o fato de seus valores serem maiores que 2 ^ 32-1 (valor máximo positivo que o inteiro pode armazenar), considere mudar para BigInt - com 64 bits ( 8 bytes) .