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 recentemente propôs alterar o tipo de dados DECIMAL(5,0)para recuperar algum armazenamento.
De acordo com a biblioteca do MSDN , o espaço de armazenamento do DECIMAL(5,0)tipo de dados é, assim como o DECIMAL(9,0)tipo de dados, 5 bytes. INTé 1 byte menor, mas pode armazenar tudo no intervalo de -2 ^ 31 a 2 ^ 31 em vez dos -99.999 a 99.999 que DECIMAL(5,0)podem ser armazenados. Mesmo o maior DECIMALque se encaixa 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 da faixa INToferecida em 4 bytes).
Posso pensar em dois "benefícios" do uso DECIMALexcessivo INT:
- A capacidade de adicionar escala posteriormente, sem usar mais espaço de armazenamento
- A capacidade de escalar a precisão em 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 muito poucos casos (na maioria dos casos em que a escala faz diferença, ela também pode ser adicionada com antecedência)
- 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?
fonte
decimal(x,0)e um tipo inteiro mostra-se na divisão aritmética. Se você dividir um int por um int, você obtém um int. Se você dividir um decimal (x, 0) por um int, obtém um decimal (x + 6,6).Respostas:
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 que o DECIMAL se dividirá naturalmente em um tipo que não perde 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 nos valores), pois elas são canalizadas com mais eficiência pela CPU. Uma comparação int são dois códigos de montagem (MOV, CMP), mas qualquer comparação decimal será muito, muito mais.
fonte
DECIMAL(9, 0)invés de umINT?DECIMALainda demorar um pouco mais (pelo menos no meu sistema de desenvolvimento). Em uma execução de 10 testes em torno de 51 ms DEC vs. 46 ms INT.Parece que não haverá benefícios em termos de espaço de armazenamento.
Se o seu cliente está preocupado com o fato de seus valores serem maiores que 2 ^ 32-1 (o valor máximo positivo inteiro pode armazenar), você deve considerar a mudança para BigInt - com 64 bits ( 8 bytes) .
fonte