Você deve escolher os tipos de dados DINHEIRO ou DECIMAL (x, y) no SQL Server?

Estou curioso para saber se existe ou não uma diferença real entre o moneytipo de dados e algo como decimal(19,4)(que é o que o dinheiro usa internamente, acredito).

Estou ciente de que moneyé específico para o SQL Server. Quero saber se há um motivo convincente para escolher um sobre o outro; a maioria das amostras do SQL Server (por exemplo, o banco de dados AdventureWorks) usa moneye não decimalpara informações como preço.

Devo apenas continuar usando o tipo de dados money ou há um benefício em usar decimal? O dinheiro tem menos caracteres para digitar, mas esse não é um motivo válido :)

Nunca você deve usar dinheiro. Não é preciso e é puro lixo; sempre use decimal / numérico.

Execute isso para ver o que quero dizer:

DECLARE
    @mon1 MONEY,
    @mon2 MONEY,
    @mon3 MONEY,
    @mon4 MONEY,
    @num1 DECIMAL(19,4),
    @num2 DECIMAL(19,4),
    @num3 DECIMAL(19,4),
    @num4 DECIMAL(19,4)

    SELECT
    @mon1 = 100, @mon2 = 339, @mon3 = 10000,
    @num1 = 100, @num2 = 339, @num3 = 10000

    SET @mon4 = @mon1/@mon2*@mon3
    SET @num4 = @num1/@num2*@num3

    SELECT @mon4 AS moneyresult,
    @num4 AS numericresult

Saída: 2949.0000 2949.8525

Para algumas das pessoas que disseram que você não divide dinheiro por dinheiro:

Aqui está uma das minhas consultas para calcular correlações, e mudar isso para dinheiro gera resultados incorretos.

select t1.index_id,t2.index_id,(avg(t1.monret*t2.monret)
    -(avg(t1.monret) * avg(t2.monret)))
            /((sqrt(avg(square(t1.monret)) - square(avg(t1.monret))))
            *(sqrt(avg(square(t2.monret)) - square(avg(t2.monret))))),
current_timestamp,@MaxDate
            from Table1 t1  join Table1 t2  on t1.Date = traDate
            group by t1.index_id,t2.index_id

O SQLMenace disse que o dinheiro é inexato. Mas você não multiplica / divide dinheiro por dinheiro! Quanto é 3 dólares vezes 50 centavos? 150 dollarcents? Você multiplica / divide dinheiro por escalares, que devem ser decimais.

DECLARE
@mon1 MONEY,
@mon4 MONEY,
@num1 DECIMAL(19,4),
@num2 DECIMAL(19,4),
@num3 DECIMAL(19,4),
@num4 DECIMAL(19,4)

SELECT
@mon1 = 100,
@num1 = 100, @num2 = 339, @num3 = 10000

SET @mon4 = @mon1/@num2*@num3
SET @num4 = @num1/@num2*@num3

SELECT @mon4 AS moneyresult,
@num4 AS numericresult

Resultados no resultado correto:

moneyresult numericresult
--------------------- ----------------------------- ----------
2949.8525 2949.8525

moneyé bom desde que você não precise mais do que quatro dígitos decimais e verifique se seus escalares - que não representam dinheiro - são decimals.

Tudo é perigoso se você não sabe o que está fazendo

Mesmo os tipos decimais de alta precisão não podem salvar o dia:

declare @num1 numeric(38,22)
declare @num2 numeric(38,22)
set @num1 = .0000006
set @num2 = 1.0
select @num1 * @num2 * 1000000

1.000000 <- deve ser 0,6000000

Os moneytipos são inteiros

As representações de texto smallmoneye decimal(10,4)podem ser parecidas, mas isso não as torna intercambiáveis. Você se encolhe quando vê datas armazenadas como varchar(10)? Isso é a mesma coisa.

Nos bastidores, money/ smallmoneysão apenas um bigint/ int O ponto decimal na representação de texto moneyé um buço visual, assim como os traços em uma data aaaa-mm-dd. SQL não armazena esses internamente.

Em relação a decimalvs money, escolha o que for apropriado para suas necessidades. Os moneytipos existem porque o armazenamento de valores contábeis como múltiplos inteiros de 1/10000 de unidade é muito comum. Além disso, se você estiver lidando com dinheiro e cálculos reais além da simples adição e subtração, não deve fazer isso no nível do banco de dados! Faça isso no nível do aplicativo com uma biblioteca que suporte o Banker's Rounding (IEEE 754)

Sei que WayneM afirmou que sabe que o dinheiro é específico para o SQL Server. No entanto, ele está perguntando se há algum motivo para usar dinheiro em decimal ou vice-versa e acho que um motivo óbvio ainda deve ser declarado e que o uso de decimal significa que é menos uma coisa com que se preocupar se você precisar alterar seu DBMS - o que pode acontecer.

Torne seus sistemas o mais flexível possível!

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 INTegers, 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 MONEYquando o que você está lidando é MONEYe usá-lo de acordo com as regras matemáticas a seguir (o mesmo que INTeger).

Teria sido melhor se o SQL Server promovesse a divisão e multiplicação de MONEYs em DECIMALs (ou FLOATs?) - possivelmente, mas eles não escolheram fazer isso; nem escolheram promover INTegers to FLOATs ao dividi-los.

MONEYnão tem problema de precisão; que DECIMALs 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 xpode ser um DECIMALou outro MONEY, MONEYterá 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, DECIMALsofre 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 DECIMALarredondado em vez de MONEYtruncado - o mesmo que um número inteiro.)

Acabamos de nos deparar com um problema muito semelhante e agora sou um +1 por nunca usar o Money, exceto na apresentação de nível superior. Temos várias tabelas (efetivamente um comprovante de vendas e uma fatura de vendas), cada uma das quais contém um ou mais campos do Money por motivos históricos, e precisamos executar um cálculo proporcional para determinar quanto do imposto total da fatura é relevante para cada um. linha no comprovante de vendas. Nosso cálculo é

vat proportion = total invoice vat x (voucher line value / total invoice value)

Isso resulta em um cálculo de dinheiro / dinheiro do mundo real que causa erros de escala na parte da divisão, que então se multiplica em uma proporção incorreta do tanque. Quando esses valores são adicionados posteriormente, terminamos com uma soma das proporções de IVA que não somam o valor total da fatura. Se um dos valores entre parênteses fosse decimal (estou prestes a lançar um deles como tal), a proporção da cuba estaria correta.

Quando os colchetes não estavam lá originalmente, isso costumava funcionar, acho que por causa dos valores maiores envolvidos, ele efetivamente simulava uma escala mais alta. Adicionamos os colchetes porque ele fazia a multiplicação primeiro, o que, em alguns casos raros, diminuía a precisão disponível para o cálculo, mas isso agora causou esse erro muito mais comum.

Como um contraponto ao impulso geral das outras respostas. Veja os muitos benefícios do dinheiro ... Tipo de dados! no Guia do SQLCAT para o mecanismo relacional

Especificamente, gostaria de salientar o seguinte

Trabalhando nas implementações de clientes, encontramos alguns números de desempenho interessantes sobre o tipo de dados monetários. Por exemplo, quando o Analysis Services foi definido como o tipo de dados da moeda (do dobro) para corresponder ao tipo de dados monetários do SQL Server, houve uma melhoria de 13% na velocidade de processamento (linhas / s). Para obter um desempenho mais rápido no SSIS (SQL Server Integration Services) para carregar 1,18 TB em menos de trinta minutos, conforme observado no SSIS 2008 - desempenho ETL recorde mundial, observou-se que a alteração das quatro colunas decimais (9,2) com um tamanho de 5 bytes na tabela TPC-H LINEITEM em dinheiro (8 bytes) melhoraram a velocidade de inserção em massa em 20% ... O motivo da melhoria de desempenho é devido ao protocolo TDS (Tabular Data Stream) do SQL Server, que possui o principal princípio de design para transferir dados em formato binário compacto e o mais próximo possível do formato de armazenamento interno do SQL Server. Empiricamente, isso foi observado durante o SSIS 2008 - teste de desempenho ETL recorde mundial usando Kernrate; o protocolo caiu significativamente quando o tipo de dados foi mudado para dinheiro a partir de decimal. Isso torna a transferência de dados o mais eficiente possível. Um tipo de dados complexo precisa de análise e ciclos de CPU adicionais para lidar com um tipo de largura fixa.

Portanto, a resposta para a pergunta é "depende". Você precisa ter mais cuidado com certas operações aritméticas para preservar a precisão, mas pode achar que as considerações de desempenho valem a pena.

Quero dar uma visão diferente de DINHEIRO vs. NUMÉRICO, com base amplamente em minha própria experiência e experiência ... Meu ponto de vista aqui é DINHEIRO, porque eu trabalhei com ele por um longo tempo e nunca usei muito NUMÉRICO .. .

DINHEIRO Pro:

• Tipo de dados nativo . Ele usa um tipo de dados nativo ( inteiro ) igual ao registro da CPU (32 ou 64 bits), para que o cálculo não precise de sobrecarga desnecessária, por isso é menor e mais rápido ... O DINHEIRO precisa de 8 bytes e NUMÉRICO (19, 4 ) precisa de 9 bytes (12,5% maior) ...

  O DINHEIRO é mais rápido, desde que seja usado para o que deveria ser (como dinheiro). Quão rápido? Meu SUMteste simples com 1 milhão de dados mostra que o DINHEIRO é 275 ms e o NUMERIC 517 ms ... Isso é quase o dobro da velocidade ... Por que o teste SUM? Veja o próximo ponto Pro

• Melhor por dinheiro . O DINHEIRO é melhor para armazenar dinheiro e realizar operações, por exemplo, em contabilidade. Um único relatório pode executar milhões de adições (SUM) e algumas multiplicações após a conclusão da operação SUM. Para aplicações contábeis muito grandes, é quase o dobro da velocidade e é extremamente significativo ...
• Baixa precisão de dinheiro . Dinheiro na vida real não precisa ser muito preciso. Quero dizer, muitas pessoas podem se importar com 1 centavo de dólar, mas que cerca de 0,01 centavo? De fato, no meu país, os bancos não se preocupam mais com centavos (dígito após vírgula decimal); Eu não sei sobre o banco dos EUA ou outro país ...

DINHEIRO Con:

• Precisão limitada . O DINHEIRO possui apenas quatro dígitos (após a vírgula) de precisão, portanto, ele precisa ser convertido antes de realizar operações como divisão ... Mas, novamente money, não precisa ser tão preciso e deve ser usado como dinheiro, não apenas como número...

Mas ... Grande, mas aqui está mesmo seu aplicativo envolvido com dinheiro real, mas não o use em muitas operações SUM, como na contabilidade. Se você usar muitas divisões e multiplicações, não deverá usar DINHEIRO ...

Todas as postagens anteriores trazem pontos válidos, mas alguns não respondem à pergunta com precisão.

A pergunta é: por que alguém prefere dinheiro quando já sabemos que é um tipo de dados menos preciso e pode causar erros se usado em cálculos complexos?

Você usa dinheiro quando não faz cálculos complexos e pode trocar essa precisão por outras necessidades.

Por exemplo, quando você não precisa fazer esses cálculos e precisa importar dados de cadeias de texto de moeda válidas. Essa conversão automática funciona apenas com o tipo de dados MONEY:

SELECT CONVERT(MONEY, '$1,000.68')

Eu sei que você pode fazer sua própria rotina de importação. Mas, às vezes, você não deseja recriar uma rotina de importação com formatos de código de idioma específicos em todo o mundo.

Outro exemplo, quando você não precisa fazer esses cálculos (é necessário apenas armazenar um valor) e salvar 1 byte (o dinheiro leva 8 bytes e o decimal (19,4) leva 9 bytes). Em algumas aplicações (CPU rápida, grande RAM, E / S lenta), como apenas ler uma quantidade enorme de dados, isso também pode ser mais rápido.

Você não deve usar dinheiro quando precisar fazer multiplicações / divisões no valor. O dinheiro é armazenado da mesma maneira que um número inteiro é armazenado, enquanto o decimal é armazenado como um ponto decimal e dígitos decimais. Isso significa que o dinheiro diminui a precisão na maioria dos casos, enquanto o decimal só o faz quando convertido de volta à sua escala original. O dinheiro é ponto fixo, portanto sua escala não muda durante os cálculos. No entanto, como é um ponto fixo quando é impressa como uma sequência decimal (em oposição a uma posição fixa em uma sequência base 2), os valores até a escala de 4 são representados exatamente. Portanto, para adição e subtração, o dinheiro é bom.

Um decimal é representado internamente na base 10 e, portanto, a posição do ponto decimal também é baseada no número da base 10. O que faz com que sua parte fracionária represente seu valor exatamente, exatamente como no dinheiro. A diferença é que valores intermediários de decimal podem manter a precisão até 38 dígitos.

Com um número de ponto flutuante, o valor é armazenado em binário como se fosse um número inteiro, e a posição do ponto decimal (ou binário, ahem) é relativa aos bits que representam o número. Por ser um ponto decimal binário, os números da base 10 perdem a precisão logo após o ponto decimal. 1/5, ou 0,2, não pode ser representado com precisão dessa maneira. Nem dinheiro nem decimal sofrem com essa limitação.

É fácil converter dinheiro para decimal, executar os cálculos e depois armazenar o valor resultante em um campo ou variável monetário.

No meu ponto de vista, quero que coisas que acontecem com números aconteçam sem ter que pensar muito neles. Se todos os cálculos forem convertidos em decimal, então eu gostaria de usar decimal. Eu salvaria o campo do dinheiro para fins de exibição.

Em termos de tamanho, não vejo diferença suficiente para mudar de idéia. O dinheiro ocupa de 4 a 8 bytes, enquanto o decimal pode ser 5, 9, 13 e 17. Os 9 bytes podem cobrir todo o intervalo que os 8 bytes de dinheiro. Em termos de índice (a comparação e a pesquisa devem ser comparáveis).

Encontrei uma razão para usar decimal sobre dinheiro em assuntos de precisão.

DECLARE @dOne   DECIMAL(19,4),
        @dThree DECIMAL(19,4),
        @mOne   MONEY,
        @mThree MONEY,
        @fOne   FLOAT,
        @fThree FLOAT

 SELECT @dOne   = 1,
        @dThree = 3,    
        @mOne   = 1,
        @mThree = 3,    
        @fOne   = 1,
        @fThree = 3

 SELECT (@dOne/@dThree)*@dThree AS DecimalResult,
        (@mOne/@mThree)*@mThree AS MoneyResult,
        (@fOne/@fThree)*@fThree AS FloatResult

Resultado decimal> 1.000000

MoneyResult> 0.9999

Resultado da flutuação> 1

Basta testá-lo e tomar sua decisão.

Acabei de ver esta entrada do blog: Dinheiro vs. decimal no SQL Server .

O que basicamente diz que o dinheiro tem um problema de precisão ...

declare @m money
declare @d decimal(9,2)

set @m = 19.34
set @d = 19.34

select (@m/1000)*1000
select (@d/1000)*1000

Para o moneytipo, você receberá 19.30 em vez de 19.34. Não tenho certeza se existe um cenário de aplicativo que divide dinheiro em 1000 partes para cálculo, mas este exemplo expõe algumas limitações.