Le soucis dans ta logique est que tu parles de choses qui n'existent pas.
10.222€ n'existe pas.
Attention : je ne dis pas que 10.222 n'existe pas, mais qu'en monétaire on va regarder 10.22 et que seul 10.22 existe en €.
par exemple, sur un portefeuille de part, on pourra dire que tu as 1000 actions à 0.010222€ virtuels (calcul intermédiaire), quand on va te les payer ce sera bien 10.22€ qu'on te filera et pas 0.002€ de plus.
Je prend l'exemple de l'essence ci-dessus, si le litre est à 1.234€ affiché et que tu prends 1 litre (imaginons pas de minimum pour l'exemple), la caisse te facturera 1.23€ point (pas de 0.004€ en plus).
Tu dois donc décider :
- tu comptes des € : DECIMAL (ou autre méthode) avec 2 décimales (pour l'€), toujours arrondi.
- calculs intermédiaires : tu comptes avec d'autres règles à fixer (par exemple, si j'ai 0.13€ à payer en 12x, on me fait 11x 0.01€ puis 1x0.02€; autre exemple avec la TVA, si tu veux vendre à 0.99€ tu ne vas pas faire le HT à 0.99/1.2=0.825 et TVA = 0.825*0.2=0.165, car comment tu vas payer ta TVA avec 0.005€? tu fais 0.99/1.2=0.825 arrondi donc à 0.83,ドル et la TVA est 0.16,ドル différent de si tu avais fait l'arrondi de la TVA car ça aurait donné 0.17,ドル j'apprends ça en ce moment en découvrant les problèmes d'arrondis sur TVA avec des phases intérmédiaires, allez pour rigoler différente méthodes d'arrondis)
Bref, il y a des règles, qu'il faut connaitre, de quand et comment tu arrondis, ce n'est pas forcément une question de DECIMAL ou DOUBLE, mais un gestion bien précise des règles (quand et comment arrondir), un programme qui va utiliser un arrondi par défaut en monétaire est juste mauvais, et un programme qui va filer 10.222 à un DECIMAL(10,2) est mal barré car n'a pas appliqué la règle définie par la compta, mais est-ce que ça existe?
# "10.222" n'existe pas
Posté par Zenitram (site web personnel) . En réponse au journal SQL Decimal vs Double. Évalué à 6. Dernière modification le 11 septembre 2017 à 15:59.
Le soucis dans ta logique est que tu parles de choses qui n'existent pas.
10.222€ n'existe pas.
Attention : je ne dis pas que 10.222 n'existe pas, mais qu'en monétaire on va regarder 10.22 et que seul 10.22 existe en €.
par exemple, sur un portefeuille de part, on pourra dire que tu as 1000 actions à 0.010222€ virtuels (calcul intermédiaire), quand on va te les payer ce sera bien 10.22€ qu'on te filera et pas 0.002€ de plus.
Je prend l'exemple de l'essence ci-dessus, si le litre est à 1.234€ affiché et que tu prends 1 litre (imaginons pas de minimum pour l'exemple), la caisse te facturera 1.23€ point (pas de 0.004€ en plus).
Tu dois donc décider :
- tu comptes des € : DECIMAL (ou autre méthode) avec 2 décimales (pour l'€), toujours arrondi.
- calculs intermédiaires : tu comptes avec d'autres règles à fixer (par exemple, si j'ai 0.13€ à payer en 12x, on me fait 11x 0.01€ puis 1x0.02€; autre exemple avec la TVA, si tu veux vendre à 0.99€ tu ne vas pas faire le HT à 0.99/1.2=0.825 et TVA = 0.825*0.2=0.165, car comment tu vas payer ta TVA avec 0.005€? tu fais 0.99/1.2=0.825 arrondi donc à 0.83,ドル et la TVA est 0.16,ドル différent de si tu avais fait l'arrondi de la TVA car ça aurait donné 0.17,ドル j'apprends ça en ce moment en découvrant les problèmes d'arrondis sur TVA avec des phases intérmédiaires, allez pour rigoler différente méthodes d'arrondis)
Bref, il y a des règles, qu'il faut connaitre, de quand et comment tu arrondis, ce n'est pas forcément une question de DECIMAL ou DOUBLE, mais un gestion bien précise des règles (quand et comment arrondir), un programme qui va utiliser un arrondi par défaut en monétaire est juste mauvais, et un programme qui va filer 10.222 à un DECIMAL(10,2) est mal barré car n'a pas appliqué la règle définie par la compta, mais est-ce que ça existe?