web-dev-qa-db-fra.com

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 à cette fin?
VARCHARouINT(ou d'autres types de données numériques)?

mysqlsqldatatypescurrency
237
Mohammad Saberi

Comme l'argent a besoin d'une représentation exacte, n'utilisez pas de types de données approximatifs, comme 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 les données monétaire.

319
juergen d

Vous pouvez utiliser DECIMAL ou NUMERIC les deux 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 étant implémenté en tant que DECIMAL, les remarques suivantes à propos de DECIMAL s'appliquent également à NUMERIC. : MySQL

i.e. _DECIMAL(10,2)

Example settings

Bonne lecture

82
NullPoiиteя

Je préfère utiliser BIGINT et stocker les valeurs dans par multiplier par 100, de sorte qu'il devienne un entier. 

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

Mise en garde:
La plupart du temps, nous n’effectuons pas la multiplication currency * currency; au cas où nous le ferions, divisons le résultat par 100 et stockons-le afin qu’il revienne à la précision appropriée.

28
Dinesh P.R.

Cela dépend de vos besoins.

Utiliser DECIMAL(10,2) suffit généralement, mais si vous avez besoin de valeurs un peu plus précises, définissez DECIMAL(10,4).

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

26
Svetoslav

Si votre application doit gérer des valeurs monétaires allant jusqu'à un billion de dollars, cela devrait fonctionner: 13,2 Si vous devez respecter les principes comptables généralement reconnus (GAAP), utilisez: 13,4.

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

13
david.ee

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

5
Chagbert

À l'époque, cette question avait été posée, personne ne pensait au prix Bitcoin. Dans le cas de BTC, il est probablement insuffisant d’utiliser DECIMAL(15,2). Si le bitcoin doit atteindre 100 000 $ ou plus, nous aurons besoin d'au moins DECIMAL(18,9) pour prendre en charge les crypto-devises dans nos applications.

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

3
bizwiz

Essayez d'utiliser

Decimal(19,4)

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

3
Deepesh

Nous utilisons double.

* halètement *

Pourquoi?

Parce qu’il peut représenter n’importe quel nombre de 15 chiffres sans contrainte sur le point. Tout cela pour un maigre 8 octets!

Donc, cela peut représenter:

  • 0.123456789012345
  • 123456789012345.0

... et rien entre les deux.

Ceci est utile car nous traitons avec global c currency et double peut stocker les différents nombres de décimales que nous allons probablement rencontrer.

Un seul champ double peut représenter 999 999 999 999 999 en yens japonais, 9 999 999 999 999,99 en dollars américains et même 9 999 999 999 999999 en bitcoins

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

Mises en garde

Bien sûr, utiliser double ne va pas sans réserves.

Cependant, ce n'est pas une perte de précision, comme certains le font remarquer. Même si double lui-même peut ne pas être en interne exact par rapport au système base 10, nous pouvons le rendre exact en en arrondissant la valeur nous tirons de la base de données à ses décimales significatives. Si besoin est. (Par exemple, si le résultat doit être généré et si une représentation en base 10 est requise.)

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

  1. Effectuer des comparaisons à ce sujet.
  2. L'écrire dans la base de données.

Un autre type d’avertissement est que, contrairement à decimal(m, d) où la base de données empêchera les programmes d’insérer un nombre de plus de m chiffres, 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 sera finalement enregistré silencieusement comme un montant inexact.

2
antak

Stocker de l'argent sous la forme BIGINT, multiplié par 100 ou plus, en utilisant moins d'espace de stockage n'a aucun sens dans toutes les situations "normales".

1
digitalstraw

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

0
auntyellow