Eu quero armazenar muitos registros em um banco de dados MySQL. Todos eles contêm valores monetários. Mas não sei quantos dígitos serão inseridos para cada um.
Que tipo de dados eu tenho que usar para esse fim?
VARCHAR ou INT (ou outros tipos de dados numéricos)?
Respostas:
Como o dinheiro precisa de uma representação exata, não use tipos de dados que sejam apenas aproximados float. Você pode usar um tipo de dados numérico de ponto fixo para algo como
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 decimalVeja Tipos Numéricos do MySQL :
Esses tipos são usados quando é importante preservar a precisão exata, por exemplo, com dados monetários .
decimale numericsão os mesmos.
numeric(19,4)para registros financeiros que oferecem uma mão melhor para você jogar e adotar novos pedidos com facilidade.
Você pode usar DECIMALou NUMERICambos são iguais
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, portanto, as seguintes observações sobre DECIMAL se aplicam igualmente a NUMERIC. : MySQL
ie DECIMAL(10,2)
Eu prefiro usar BIGINTe armazenar os valores multiplicando por 100 , para que ele se torne um número inteiro.
Por exemplo, para representar um valor de moeda de 93.49, o valor deve ser armazenado como 9349, ao exibir o valor que podemos dividir por 100 e exibir. Isso ocupará menos espaço de armazenamento.
Cuidado:
Principalmente não realizamoscurrency * currencymultiplicação; caso contrário, divida o resultado com 100 e armazene, para que ele retorne à precisão adequada.
DECIMAL? Você cria a necessidade de converter moedas de um centavo para dólares, e ai se você a esquecer em algum momento.
$0.005ou $0.12345) porque eles não serão reduzidos a um número inteiro depois de multiplicados por 100. Se você souber a precisão dos valores, desmarque a caixa A melhor opção é usar DECIMAL. Mas se você não souber a precisão (como nos meus exemplos), então… seria FLOATapropriado?
Depende da sua necessidade.
Usar DECIMAL(10,2)normalmente é suficiente, mas se você precisar de valores um pouco mais precisos, poderá definir DECIMAL(10,4).
Se você trabalha com grandes valores, substitua 10por 19.
Se o seu aplicativo precisar lidar com valores monetários de até um trilhão, isso deve funcionar: 13,2 Se você precisar cumprir os GAAP (princípios de contabilidade geralmente aceitos), use: 13,4
Normalmente, você deve somar seus valores monetários em 13,4 antes de arredondar a saída para 13,2.
De fato, 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 ) .
double.*suspiro*
Porque ele pode representar qualquer número de 15 dígitos sem restrições sobre onde está o ponto decimal . Tudo por um mísero 8 bytes!
Portanto, pode representar:
0.123456789012345123456789012345.0... e qualquer coisa no meio.
Isso é útil porque estamos lidando com moedas globais e doublepode armazenar os vários números de casas decimais que provavelmente encontraremos.
Um único doublecampo pode representar 999.999.999.999.999s em ienes japoneses, 9.999.999.999.999.999s em dólares americanos e até 9.999.999.9999999999s em bitcoins
Se você tentar fazer o mesmo decimal, precisará de um decimal(30, 15)custo de 14 bytes.
Claro, o uso doublenão é sem ressalvas.
No entanto, não é perda de precisão, como alguns tendem a apontar. Mesmo que doubleele próprio não seja internamente exato para o sistema base 10 , podemos torná-lo exato arredondando o valor que extraímos do banco de dados para suas casas decimais significativas. Se necessário, é isso. (por exemplo, se for produzido, e a representação da base 10 é necessária.)
As advertências são: sempre que executamos aritmética com ele, precisamos normalizar o resultado (arredondando-o para suas casas decimais significativas) antes de:
Outro tipo de ressalva é que, diferentemente de decimal(m, d)onde o banco de dados impedirá que os programas insiram um número com mais de mdígitos, essas validações não existem double. Um programa pode inserir um valor digitado pelo usuário de 20 dígitos e acabará sendo gravado silenciosamente como uma quantidade imprecisa.
1.410000000000(doze casas decimais significativas), mas multiplicando isso por 1.000.000.000.000 (que são 13 dígitos significativos à esquerda do ponto decimal) significa que estamos trabalhando em menos 25 dígitos combinados de significância. Isso supera em muito os 15 disponíveis para um duplo, então, em termos de design, acho que seria muito quebrado.
Na época, essa pergunta foi feita e ninguém pensou no preço do Bitcoin. No caso do BTC, provavelmente é insuficiente para usar DECIMAL(15,2). Se o Bitcoin subir para US $ 100.000 ou mais, precisaremos pelo menos DECIMAL(18,9)oferecer suporte a criptomoedas em nossos aplicativos.
DECIMAL(18,9)ocupa 12 bytes de espaço no MySQL ( 4 bytes por 9 dígitos ).
Armazenar dinheiro BIGINTmultiplicado por 100 ou mais com o motivo de usar menos espaço de armazenamento não faz sentido em todas as situações "normais".
DECIMAL(13,4)DECIMAL.
DECIMAL(13,4) representa 9 dígitos + 4 dígitos da fração (casas decimais) => 4 + 2 bytes = 6 bytesBIGINT.Se a conformidade com o GAAP for necessária ou você precisar de quatro casas decimais:
DECIMAL (13, 4) Que suporta um valor máximo de:
$ 999.999.999.9999
Caso contrário, se duas casas decimais forem suficientes: DECIMAL (13,2)
src: https://rietta.com/blog/best-data-types-for-currencymoney-in/
Multiplica 10000 e armazena como BIGINT, como "Moeda" no Visual Basic e no Office. Consulte https://msdn.microsoft.com/en-us/library/office/gg264338.aspx
deimal(10,2)é o que eu uso ... você pode ajustar os valores, dependendo do tamanho esperado