Quel est le meilleur type de données SQL pour les valeurs monétaires? J'utilise MySQL mais préférerais un type indépendant de la base de données.
Réponses:
Quelque chose comme ça Decimal(19,4)fonctionne généralement bien dans la plupart des cas. Vous pouvez ajuster l'échelle et la précision pour répondre aux besoins des nombres que vous devez stocker. Même dans SQL Server, j'ai tendance à ne pas utiliser " money" car il n'est pas standard.
(19,4)place de (19,2)?
La seule chose à laquelle vous devez faire attention est que si vous migrez d'une base de données à une autre, vous pouvez constater que DECIMAL (19,4) et DECIMAL (19,4) signifient des choses différentes
( http://dev.mysql.com/doc/refman/5.1/en/precision-math-decimal-changes.html )
DBASE: 10,5 (10 entier, 5 décimal)
MYSQL: 15,5 (15 chiffres, 10 entiers (15-5), 5 décimaux)
Il est également important de déterminer combien de décimales peuvent être nécessaires pour vos calculs.
J'ai travaillé sur une application de cours de bourse qui nécessitait le calcul du prix d'un million d'actions. Le prix de l'action coté devait être stocké à 7 chiffres de précision.
Réponse d'Assaf de
Cela dépend de combien d'argent vous avez ...
semble désinvolte, mais en fait c'est pertinent.
Aujourd'hui seulement, nous avons eu un problème où un enregistrement n'a pas pu être inséré dans notre table de taux, car l'une des colonnes (GrossRate) est définie sur Decimal (11,4), et notre service produit vient d'obtenir un contrat pour des chambres dans un complexe incroyable à Bora Bora, qui se vendent plusieurs millions de francs pacifiques par nuit ... ce qui n'avait jamais été prévu lorsque le schéma de la base de données a été conçu il y a 10 ans.
Pour les applications comptables, il est très courant de stocker les valeurs sous forme d'entiers (certains vont même jusqu'à dire que c'est le seul moyen). Pour vous faire une idée, prenez le montant des transactions (supposons 100,23 $) et multiple de 100, 1000, 10000, etc. pour obtenir la précision dont vous avez besoin. Donc, si vous avez seulement besoin de stocker des cents et que vous pouvez arrondir vers le haut ou vers le bas en toute sécurité, multipliez simplement par 100. Dans mon exemple, cela ferait 10023 comme entier à stocker. Vous économiserez de l'espace dans la base de données et comparer deux entiers est beaucoup plus facile que de comparer deux flottants. Mon 0,02 $.
DECIMAL? Vous devez faire très attention à toujours convertir des pièces de monnaie, des moulins ou des millrays en dollars, aux moments appropriés.
entrée super tardive mais les PCGR sont une bonne règle de base ..
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.
Source: meilleur type de données pour stocker la valeur monétaire dans MySQL
Vous pouvez utiliser quelque chose comme DECIMAL(19,2)par défaut pour toutes vos valeurs monétaires, mais si vous ne stockez jamais que des valeurs inférieures à 1000 $, cela va juste être un gaspillage d'espace de base de données précieux.
Pour la plupart des implémentations, ce DECIMAL(N,2)serait suffisant, où la valeur de Nest au moins le nombre de chiffres avant .la plus grande somme que vous vous attendiez à être stockée dans ce champ + 5. Donc, si vous ne vous attendez jamais à stocker des valeurs supérieures à 999999,99, cela DECIMAL(11,2)devrait être plus que suffisant (jusqu'à ce que les attentes changent).
Si vous voulez être conforme aux PCGR , vous pouvez aller avec DECIMAL(N,4), où la valeur de Nest au moins le nombre de chiffres avant .la plus grande somme que vous vous attendez à être stockée dans ce champ + 7.
Cela dépend de la nature des données. Vous devez le contempler au préalable.
Bien que MySQL vous permette d'utiliser décimal (65,30), 31 pour l'échelle et 30 pour la précision semblent être nos limites si nous voulons laisser l'option de transfert ouverte.
Échelle et précision maximales dans les SGBDR les plus courants:
Échelle de précision Oracle 31 31 T-SQL 38 38 MySQL 65 30 PostgreSQL 131072 16383
Septembre 2015 Le gouvernement zimbabwéen a annoncé qu'il échangerait des dollars zimbabwéens contre des dollars américains à un taux de 1 USD à 35 quadrillions de dollars zimbabwéens 5
Nous avons tendance à dire "oui, bien sûr ... je n'aurai pas besoin de ces chiffres fous". Eh bien, les Zimbabwéens disaient ça aussi. Il n'y a pas si longtemps.
Imaginons que vous ayez besoin d'enregistrer une transaction de 1 mln USD en dollars zimbabwéens (peut-être peu probable aujourd'hui, mais qui sait à quoi cela ressemblera dans 10 ans?).
- (1 mln USD) * (35 Quadrylion ZWL) = (10 ^ 6) * (35 * 10 ^ 15) = 35 * 10 ^ 21
- nous avons besoin:
- 2 chiffres pour enregistrer "35"
- 21 chiffres pour stocker les zéros
- 4 chiffres à droite du séparateur décimal
- cela fait décimal (27,4) qui nous coûte 15 octets pour chaque entrée
- nous pouvons ajouter un chiffre à gauche sans frais - nous avons un nombre décimal (28,4) pour 15 octets
- Maintenant, nous pouvons stocker une transaction de 10 millions USD exprimée en dollars zimbabwéens, ou à l'abri d'une nouvelle grève d'hiperinflation, qui, espérons-le, ne se produira pas.
Bien que cela puisse être en retard, mais cela sera utile à quelqu'un d'autre. D'après mon expérience et mes recherches, j'ai appris à connaître et à accepter les décimales (19, 6). C'est lorsque je travaille avec php et mysql. lorsque vous travaillez avec une grande quantité d'argent et un taux de change