Meilleur type de données pour stocker des valeurs monétaires dans MySQL

Je souhaite stocker de nombreux enregistrements dans une base de données MySQL. Tous contiennent des valeurs monétaires. Mais je ne sais pas combien de chiffres seront insérés pour chacun.
Quel type de données dois-je utiliser à cet effet?
VARCHAR ou INT (ou d'autres types de données numériques)?

Étant donné que l'argent a besoin d'une représentation exacte, n'utilisez pas de types de données qui ne sont qu'approximatifs float. Vous pouvez utiliser un type de données numérique à virgule fixe pour cela comme

decimal(15,2)

• 15 est la précision (longueur totale de la valeur, y compris les décimales)
• 2 est le nombre de chiffres après le point décimal

Voir Types numériques MySQL :

Ces types sont utilisés lorsqu'il est important de conserver une précision exacte, par exemple avec des données monétaires .

Vous pouvez utiliser DECIMALou les NUMERICdeux sont identiques

Les types DECIMAL et NUMERIC stockent des valeurs de données numériques exactes. Ces types sont utilisés lorsqu'il est important de conserver une précision exacte, par exemple avec des données monétaires. Dans MySQL, NUMERIC est implémenté en tant que DECIMAL, donc les remarques suivantes sur DECIMAL s'appliquent également à NUMERIC. : MySQL

c'est à dire DECIMAL(10,2)

Bonne lecture

Je préfère utiliser BIGINTet stocker les valeurs en multipliant par 100 , afin qu'il devienne entier.

Par exemple, pour représenter une valeur monétaire de 93.49, la valeur doit être stockée sous la forme 9349, tout en affichant la valeur que nous pouvons diviser par 100 et afficher. Cela occupera moins d'espace de stockage.

Attention:
Généralement, nous n'effectuons pas de currency * currencymultiplication, au cas où si nous le faisions, divisez le résultat par 100 et stockez-le, afin qu'il revienne à la bonne précision.

Cela dépend de vos besoins.

Utiliser DECIMAL(10,2)habituellement suffit mais si vous avez besoin de valeurs un peu plus précises, vous pouvez les définir DECIMAL(10,4).

Si vous travaillez avec de grandes valeurs, remplacez 10par 19.

Si votre application doit gérer des valeurs monétaires pouvant atteindre un billion, cela devrait fonctionner: 13,2 Si vous devez vous conformer aux PCGR (principes comptables généralement reconnus), utilisez: 13,4

Habituellement, vous devez additionner vos valeurs monétaires à 13,4 avant d'arrondir la sortie à 13,2.

En effet, cela dépend des préférences du programmeur. J'utilise personnellement: numeric(15,4)pour se conformer aux principes comptables généralement reconnus ( PCGR ) .

Essayez d'utiliser

Decimal(19,4)

cela fonctionne généralement avec tous les autres DB aussi

Nous utilisons double.

*haleter*

Pourquoi?

Parce qu'il peut représenter n'importe quel nombre à 15 chiffres sans aucune contrainte sur l'emplacement du point décimal . Le tout pour un maigre 8 octets!

Il peut donc représenter:

• 0.123456789012345
• 123456789012345.0

... et quoi que ce soit entre les deux.

Ceci est utile car nous avons affaire à des devises mondiales et doublepeut stocker les différents nombres de décimales que nous rencontrerons probablement.

Un seul doublechamp peut représenter 999 999 999 999 999 s en yens japonais, 9 999 999 999 999,99 s en dollars américains et même 9 999 999 99999 99999 s en bitcoins

Si vous essayez de faire de même avec decimal, vous avez besoin de decimal(30, 15)ce qui coûte 14 octets.

Avertissements

Bien sûr, l'utilisation doublen'est pas sans réserves.

Cependant, ce n'est pas une perte de précision comme certains ont tendance à le souligner. Même si doublelui-même peut ne pas être exact en interne pour le système de base 10 , nous pouvons le rendre exact en arrondissant la valeur que nous tirons de la base de données à ses décimales significatives. Si besoin est. (Par exemple, s'il doit être sorti et qu'une représentation en base 10 est requise.)

Les mises en garde sont, chaque fois que nous effectuons de l'arithmétique avec lui, nous devons normaliser le résultat (en l'arrondissant à ses décimales significatives) avant:

1. Effectuer des comparaisons dessus.
2. Le réécrire dans la base de données.

Un autre type de mise en garde est, contrairement à l' decimal(m, d)endroit où la base de données empêchera les programmes d'insérer un nombre de plus de mchiffres, aucune validation de ce type n'existe avec double. Un programme peut insérer une valeur entrée par l'utilisateur de 20 chiffres et il finira par être enregistré en silence comme un montant inexact.

Au moment où cette question a été posée, personne ne pensait au prix du Bitcoin. Dans le cas du BTC, il est probablement insuffisant à utiliser DECIMAL(15,2). Si le Bitcoin monte à 100 000 $ ou plus, nous aurons besoin au moins DECIMAL(18,9)de prendre en charge les crypto-monnaies dans nos applications.

DECIMAL(18,9)prend 12 octets d'espace dans MySQL ( 4 octets pour 9 chiffres ).

Stocker de l'argent BIGINTmultiplié par 100 ou plus avec la raison d'utiliser moins d'espace de stockage n'a aucun sens dans toutes les situations "normales".

• Pour rester aligné sur les PCGR, il suffit de stocker les devises dans DECIMAL(13,4)
• Le manuel MySQL indique qu'il a besoin de 4 octets pour 9 chiffres pour être stocké DECIMAL.
  • https://dev.mysql.com/doc/refman/8.0/en/precision-math-decimal-characteristics.html
• DECIMAL(13,4) représente 9 chiffres + 4 chiffres de fraction (décimales) => 4 + 2 octets = 6 octets
• comparer à 8 octets nécessaires pour stocker BIGINT.

Si la conformité aux PCGR est requise ou si vous avez besoin de 4 décimales:

DECIMAL (13, 4) Qui prend en charge une valeur maximale de:

999 999 999,9999 $

Sinon, si 2 décimales suffisent: DECIMAL (13,2)

src: https://rietta.com/blog/best-data-types-for-currencymoney-in/

Multiplie 10000 et stocke en BIGINT, comme "Currency" dans Visual Basic et Office. Voir https://msdn.microsoft.com/en-us/library/office/gg264338.aspx