Discussion :

[faya972]

Bonjour, je sais que ce sujet a été mainte fois abordé et je connais la solution au problème : le type DECIMAL.
Mais ici je voudrais comprendre un comportement bizarre de Mysql : le même calcul sur deux tables IDENTIQUES à part le nom me renvoie deux résultats différents !?

Je vous donne le contexte :
Une table

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

'ecriture' {INT date, INT metier, INT champ, FLOAT val}

sur laquelle je faisais des SUM(val) très simples selon différentes valeurs de date et champ.

Par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
SELECT SUM(val) FROM ecriture
WHERE date='2011-01-28' AND metier='20001'.

Ayant constaté des erreurs dans les résultats, j'ai supposé que le type FLOAT en était responsable et ai voulu modifier la colonne pour la changer en DECIMAL.

Pour être sûr de ne rien perdre de mes données, j'ai d'abord exporté ma table en SQL avec PhpMyAdmin puis je l'ai appelée ecriture2 dans le fichier .sql et l'ai importée dans la base.

À ce stade, je n'ai fait AUCUNE modification de type, j'ai donc deux tables ecriture et ecriture2 IDENTIQUES en tous points (données, index, nom des colonnes, ...)

Et quelle fut ma surprise lorsqu'en essayant mes SUM sur la colonne val de ecriture2, j'obtint le bon résultat !
N'en croyant pas mes yeux je réessaye sur ecriture ... le résultat est faux.

Après une dizaine d'essais, je me rend à l'évidence. J'obtiens deux sommes différentes pour la même requete.
Je suis passé au type DECIMAL et mon problème de départ est résolu mais j'aimerais comprendre ...

[ericd69]

Salut,

Je pense que ça vient dans la gestion de la précision et des erreurs d'arrondi qui dépend des types et de leur stockage interne...

Plus on cumule les calculs, plus on obtient des erreurs plus ou moins flagrantes et l'ordre des opérations joue en plus... Par exemple, si tu fais une simple somme d'une liste de valeurs dont tu changes l'ordre, tu peux avoir différents résultats...