Melhor tipo de dados para armazenar valores monetários no MySQL

Eu quero armazenar muitos registros em um database MySQL. Todos eles contém valores monetários. Mas não sei quantos dígitos serão inseridos para cada um.
Qual tipo de dados devo usar para essa finalidade?
VARCHAR ou INT (ou outros tipos de dados numéricos)?

Como o dinheiro precisa de uma representação exata, não use tipos de dados que sejam apenas aproximados, como float . Você pode usar um tipo de dados numéricos de ponto fixo para isso

 decimal(15,2) 
  • 15 é a precisão (comprimento total do valor, incluindo casas decimais)
  • 2 é o número de dígitos após o ponto decimal

Veja os tipos numéricos do MySQL :

Esses tipos são usados ​​quando é importante preservar a precisão exata, por exemplo, com dados monetários .

Você pode usar DECIMAL ou NUMERIC ambos são os mesmos

Os tipos DECIMAL e NUMERIC armazenam valores de dados numéricos exatos. Esses tipos são usados ​​quando é importante preservar a precisão exata, por exemplo, com dados monetários. No MySQL, NUMERIC é implementado como DECIMAL, então as seguintes observações sobre DECIMAL se aplicam igualmente a NUMERIC. : MySQL

ou seja, DECIMAL(10,2)

Exemplo de configurações

Boa leitura

Depende da sua necessidade.

Usar DECIMAL(10,2) geralmente é suficiente, mas se você precisar de valores um pouco mais precisos, você pode definir DECIMAL(10,4) .

Se você trabalha com grandes valores, substitua 10 por 19 .

Eu prefiro usar BIGINT e armazenar os valores em multiplicar com 100 , para que ele se torne inteiro.

Por exemplo, para representar um valor de moeda de 93.49 , o valor deve ser armazenado como 9349 , enquanto exibe o valor que podemos dividir por 100 e exibir. Isso ocupará menos espaço de armazenamento.

Cuidado:
Principalmente, não realizamos a multiplicação da currency * currency , no caso, se o fizermos, divida o resultado com 100 e armazene, para que ele retorne à precisão adequada.

Se a sua aplicação precisa lidar com valores monetários de até um trilhão, então isso deve funcionar: 13,2 Se você precisa estar em conformidade com o GAAP (Princípios Contábeis Geralmente Aceitos), use: 13,4

Normalmente você deve sumr seus valores em dinheiro a 13,4 antes do arredondamento da saída para 13,2.

Na verdade, isso depende das preferências do programador. Eu pessoalmente uso: numeric(15,4) para estar em conformidade com os Princípios Contábeis Geralmente Aceitos ( GAAP ) .

Tente usar

 Decimal(19,4) 

isso geralmente funciona com todos os outros DB bem

No momento em que esta pergunta foi feita, ninguém pensou no preço do Bitcoin. No caso do BTC, provavelmente é insuficiente para usar o DECIMAL(15,2) . Se o Bitcoin subir para US $ 100.000 ou mais, precisaremos de pelo menos DECIMAL(18,9) para suportar criptomoedas em nossos aplicativos.

DECIMAL(18,9) ocupa 12 bytes de espaço no MySQL ( 4 bytes por 9 dígitos ).

Nós usamos o double .

*suspiro*

Por quê?

Porque ele pode representar qualquer número de 15 dígitos sem restrições sobre onde está o ponto decimal . Tudo por uns 8 bytes desprezíveis!

Por isso, pode representar:

  • 0.123456789012345
  • 123456789012345.0

… e qualquer coisa entre.

Isso é útil porque estamos lidando com moedas globais , e o double pode armazenar os vários números de casas decimais que provavelmente encontraremos.

Um único campo double pode representar 999.999.999.999.999 em ienes japoneses, 9.999.999.999.999,99 em dólares americanos e até 9.999.999.99999999s em bitcoins

Se você tentar fazer o mesmo com decimal , precisará de decimal(30, 15) que custa 14 bytes.

Ressalvas

Claro, usar o double não é sem ressalvas.

No entanto, não é perda de precisão, como alguns tendem a apontar. Mesmo que o próprio double não seja internamente exato para o sistema base 10 , podemos torná-lo exato ao arredondar o valor que puxamos do database para suas casas decimais significativas. Se necessário, é isso. (por exemplo, se ele será enviado e a representação da base 10 será necessária.)

As advertências são, sempre que realizamos aritmética, precisamos normalizar o resultado (arredondando-o para suas casas decimais significativas) antes:

  1. Realizando comparações sobre ele.
  2. Escrevendo de volta para o database.

Outro tipo de advertência é que, ao contrário do decimal(m, d) que o database impedirá que os programas insiram um número com mais de m dígitos, tais validações não existem com o double . Um programa pode inserir um valor de 20 dígitos inserido pelo usuário e ele acabará sendo registrado silenciosamente como uma quantidade imprecisa.

Multiplica 10000 e armazena como BIGINT, como “Moeda” no Visual Basic e no Office. Consulte https://msdn.microsoft.com/pt-br/library/office/gg264338.aspx