D'après ce que je lis MONEY peut être casté en float, et si j'ai bien lu la doc, les règles qui s'appliquent sur les calculs dépendent de la locale configurée soit niveau système, soit au niveau de la base, tu n'as donc pas la souplesse que tu souhaites pour gérer plusieurs monnaies différentes.
De plus, stoker seulement en 2 ça veut souvent dire que tu as déjà arrondi tes valeurs calculées pour stoker (par exemple si tu appliques des réductions en % qui peuvent te donner des fractions en résultat).
Si je devais utiliser un type natif de la base, j'utiliserais définitivement un DECIMAL et pas un type money, en tout cas avec PostgreSQL, et surement pas un DECIMAL avec MySQL à cause des cast implicites et des pertes de précision. C'est souvent pour ça que j'ai tendance à conseiller des valeurs en 2 INTEGER et 1 VARCHAR (ou ENUM ou INTEGER) soit le montant, le delta (précision et puissance), et enfin la currency.
A noter que finalement, quand je dis "conseiller", c'est à prendre avec un peu de recul, car ça dépend aussi vraiment du besoin à la base, pour un logiciel de caisse par exemple, tu ne vas gérer qu'une currency et tu stockera toujours tout déjà arrondi puisque tu stockes la somme réellement payée, par exemple dans ce contexte tout ce que je viens de dire semble relativement inutile.
[^] # Re: Monnaie = danger
Posté par Christie Poutrelle (site web personnel) . En réponse au journal SQL Decimal vs Double. Évalué à 1. Dernière modification le 12 septembre 2017 à 10:35.
D'après ce que je lis MONEY peut être casté en float, et si j'ai bien lu la doc, les règles qui s'appliquent sur les calculs dépendent de la locale configurée soit niveau système, soit au niveau de la base, tu n'as donc pas la souplesse que tu souhaites pour gérer plusieurs monnaies différentes.
De plus, stoker seulement en 2 ça veut souvent dire que tu as déjà arrondi tes valeurs calculées pour stoker (par exemple si tu appliques des réductions en % qui peuvent te donner des fractions en résultat).
Si je devais utiliser un type natif de la base, j'utiliserais définitivement un DECIMAL et pas un type money, en tout cas avec PostgreSQL, et surement pas un DECIMAL avec MySQL à cause des cast implicites et des pertes de précision. C'est souvent pour ça que j'ai tendance à conseiller des valeurs en 2 INTEGER et 1 VARCHAR (ou ENUM ou INTEGER) soit le montant, le delta (précision et puissance), et enfin la currency.
A noter que finalement, quand je dis "conseiller", c'est à prendre avec un peu de recul, car ça dépend aussi vraiment du besoin à la base, pour un logiciel de caisse par exemple, tu ne vas gérer qu'une currency et tu stockera toujours tout déjà arrondi puisque tu stockes la somme réellement payée, par exemple dans ce contexte tout ce que je viens de dire semble relativement inutile.