Miglior tipo di dati per memorizzare valori monetari in MySQL

Voglio memorizzare molti record in un database MySQL. Tutti contengono valori monetari. Ma non so quante cifre saranno inserite per ognuna.
Quale tipo di dati devo usare per questo scopo?
VARCHAR o INT (o altri tipi di dati numerici)?

Poiché il denaro ha bisogno di una rappresentazione esatta, non utilizzare tipi di dati che sono solo approssimativi come float . È ansible utilizzare un tipo di dati numerici a virgola fissa per tale scopo

 decimal(15,2) 
  • 15 è la precisione (lunghezza totale del valore comprese le cifre decimali)
  • 2 è il numero di cifre dopo il punto decimale

Vedi i tipi numerici MySQL :

Questi tipi vengono utilizzati quando è importante preservare la precisione esatta, ad esempio con i dati monetari .

Puoi usare DECIMAL o NUMERIC entrambi sono uguali

I tipi DECIMAL e NUMERIC memorizzano valori di dati numerici esatti. Questi tipi vengono utilizzati quando è importante preservare la precisione esatta, ad esempio con i dati monetari. In MySQL, NUMERIC è implementato come DECIMAL, quindi le seguenti considerazioni su DECIMAL si applicano allo stesso modo a NUMERIC. : MySQL

cioè DECIMAL(10,2)

Impostazioni di esempio

Buona lettura

Dipende dal tuo bisogno.

L’uso di DECIMAL(10,2) solito è sufficiente ma se hai bisogno di valori un po ‘più precisi puoi impostare DECIMAL(10,4) .

Se lavori con valori grandi, sostituisci 10 con 19 .

Preferisco usare BIGINT , e memorizzare i valori in moltiplicare con 100 , in modo che diventi un numero intero.

Ad esempio, per rappresentare un valore di valuta di 93.49 , il valore deve essere memorizzato come 9349 , mentre viene visualizzato il valore che possiamo dividere per 100 e visualizzare. Questo occuperà meno spazio di archiviazione.

Attenzione:
Per lo più non eseguiamo la moltiplicazione della currency * currency , nel caso in cui lo facciamo dividiamo il risultato con 100 e lo memorizziamo, in modo che ritorni alla precisione corretta.

Se la tua applicazione ha bisogno di gestire valori monetari fino a un trilione, allora dovrebbe funzionare: 13,2 Se devi rispettare i GAAP (Principi contabili generalmente accettati), allora usa: 13,4

Di solito dovresti sumre i tuoi valori in denaro a 13,4 prima di arrotondare l’output a 13,2.

In effetti, ciò dipende dalle preferenze del programmatore. Io personalmente uso: numeric(15,4) per conformarsi ai principi contabili generalmente accettati ( GAAP ) .

Prova a usare

 Decimal(19,4) 

questo di solito funziona anche con ogni altro DB

All’epoca questa domanda è stata fatta, nessuno ha pensato al prezzo di Bitcoin. Nel caso di BTC, probabilmente non è sufficiente utilizzare DECIMAL(15,2) . Se il Bitcoin salirà a $ 100.000 o più, avremo bisogno almeno di DECIMAL(18,9) per supportare le criptovalute nelle nostre app.

DECIMAL(18,9) occupa 12 byte di spazio in MySQL ( 4 byte per 9 cifre ).

Usiamo il double .

* gasp *

Perché?

Perché può rappresentare qualsiasi numero di 15 cifre senza vincoli su dove si trova il punto decimale . Tutto per un misero 8 byte!

Quindi può rappresentare:

  • 0.123456789012345
  • 123456789012345.0

… e qualsiasi cosa nel mezzo

Questo è utile perché abbiamo a che fare con valute globali e il double può memorizzare i vari numeri di cifre decimali che probabilmente incontreremo.

Un singolo campo double può rappresentare 999,999,999,999,999 in yen giapponesi, 9,999,999,999,999,99 in dollari statunitensi e anche 9,999,999,999999999 in bitcoin

Se si tenta di fare lo stesso con decimal , è necessario il decimal(30, 15) che costa 14 byte.

Avvertenze

Naturalmente, l’uso del double non è privo di avvertimenti.

Tuttavia, non è la perdita di precisione, come alcuni tendono a sottolineare. Anche se il double stesso potrebbe non essere esatto internamente al sistema di base 10 , possiamo renderlo esatto arrotondando il valore che ricaviamo dal database alle cifre decimali significative. Se necessario, lo è. (ad es. se verrà emesso e sarà richiesta la rappresentazione di base 10).

Gli avvertimenti sono, ogni volta che eseguiamo l’aritmetica con esso, abbiamo bisogno di normalizzare il risultato (arrotondandolo alle cifre decimali significative) prima:

  1. Eseguendo confronti su di esso.
  2. Scriverlo nel database.

Un altro tipo di avvertenza è, a differenza dei decimal(m, d) cui il database impedirà ai programmi di inserire un numero con più di m cifre, non esistono convalide di questo tipo con il double . Un programma potrebbe inserire un valore inserito dall’utente di 20 cifre e finirà per essere registrato silenziosamente come una quantità inaccurata.

Moltiplica 10000 e si archivia come BIGINT, come “Valuta” in Visual Basic e Office. Vedere https://msdn.microsoft.com/en-us/library/office/gg264338.aspx