Bem, eu gosto MONEY
! É um byte mais barato que DECIMAL
, e os cálculos são mais rápidos porque (sob as cobertas) operações de adição e subtração são essencialmente operações inteiras. O exemplo de @ SQLMenace - que é um ótimo aviso para os inconscientes - pode ser aplicado igualmente a INT
egers, onde o resultado seria zero. Mas isso não é motivo para não usar números inteiros - quando apropriado .
Portanto, é perfeitamente 'seguro' e apropriado usar MONEY
quando o que você está lidando é MONEY
e usá-lo de acordo com as regras matemáticas a seguir (o mesmo que INT
eger).
Teria sido melhor se o SQL Server promovesse a divisão e multiplicação de MONEY
s em DECIMAL
s (ou FLOAT
s?) - possivelmente, mas eles não escolheram fazer isso; nem escolheram promover INT
egers to FLOAT
s ao dividi-los.
MONEY
não tem problema de precisão; que DECIMAL
s começa a ter um tipo intermediário maior usado durante cálculos é apenas um 'recurso' de usar esse tipo (e eu não sou realmente certo o quão longe que 'recurso' estende).
Para responder à pergunta específica, uma "razão convincente"? Bem, se você quiser um desempenho máximo absoluto em um local SUM(x)
onde x
pode ser um DECIMAL
ou outro MONEY
, MONEY
terá uma vantagem.
Além disso, não esqueça que é um primo menor SMALLMONEY
- apenas 4 bytes, mas atinge o máximo de 214,748.3647
- o que é bem pequeno para dinheiro - e, portanto, nem sempre é um bom ajuste.
Para provar o argumento de usar tipos intermediários maiores, se você atribuir o intermediário explicitamente a uma variável, DECIMAL
sofre o mesmo problema:
declare @a decimal(19,4)
declare @b decimal(19,4)
declare @c decimal(19,4)
declare @d decimal(19,4)
select @a = 100, @b = 339, @c = 10000
set @d = @a/@b
set @d = @d*@c
select @d
Produz 2950.0000
(ok, então pelo menos DECIMAL
arredondado em vez de MONEY
truncado - o mesmo que um número inteiro.)
DECIMAL(19, 4)
é uma escolha popular. verifique isso também verifique aqui Formatos de Moeda Mundial para decidir quantas casas decimais usar, a esperança ajuda.