De manière générale, pour le monétaire, je stocke deux INTEGER et non un DOUBLE ni un DECIMAL ni aucun autre type avec précision: le premier INTEGER contient la valeur multipliée par 10la précision - et le second contient la précision.
On calcule et on affiche la précision (2 ou 3 décimales ou autre) selon la monnaie à un moment donné, et tu peux changer globalement la configuration de la précision par monnaie à tout moment dans ton logiciel, les anciennes valeurs stockées ainsi avec la précision à côté sont à l'épreuve du temps.
Problème de cette méthodologie, tu ne peux pas laisser le SQL faire des aggrégats sur les montants si la précision diffère, c'est à la partie logicielle de le faire... Mais la cohérence dans l'espace et le temps à un coût.
Sinon certains SGBD (dont PostgreSQL) ont un type pour le monétaire, mais j'ai jamais testé.
# Monnaie = danger
Posté par Christie Poutrelle (site web personnel) . En réponse au journal SQL Decimal vs Double. Évalué à 3.
De manière générale, pour le monétaire, je stocke deux INTEGER et non un DOUBLE ni un DECIMAL ni aucun autre type avec précision: le premier INTEGER contient la valeur multipliée par 10la précision - et le second contient la précision.
On calcule et on affiche la précision (2 ou 3 décimales ou autre) selon la monnaie à un moment donné, et tu peux changer globalement la configuration de la précision par monnaie à tout moment dans ton logiciel, les anciennes valeurs stockées ainsi avec la précision à côté sont à l'épreuve du temps.
Problème de cette méthodologie, tu ne peux pas laisser le SQL faire des aggrégats sur les montants si la précision diffère, c'est à la partie logicielle de le faire... Mais la cohérence dans l'espace et le temps à un coût.
Sinon certains SGBD (dont PostgreSQL) ont un type pour le monétaire, mais j'ai jamais testé.