Quel type MySQL pour des données décimales ?

[milkiway]

Bonjour 8O

J'ai créé une grosse base de données sur Excel. Je l'ai enregistrée en CSV pour l'importer dans phpmyadmin pour en faire une base MySQL.

Le gros souci est que toutes mes valeurs décimales sont... transformées en valeur entières.
12.4 donne 12
15.57 donne 16

En fait, tout ce qui est après la virgule est zappé et le chiffre est arrondi.
Je pense que mon choix de format de "cellule" est en cause.
Mes cases sont désignées comme INT mais visiblement ça ne convient pas, que faut il choisir ?
A moins que ça ne puisse venir d'ailleurs ?

Merci

 

[blman]

Choisit FLOAT pour les décimales. INT, c'est pour les entiers
http://dev.mysql.com/doc/refman/5.0/fr/numeric-type-overview.html

 

[milkiway]

Ca fonctionne parfaitement, merci blman.

 

[blman]

De rien

Juste pour les float, assure toi que dans tes fichiers, le séparateur des décimales soit bien un point ( ex : 2.5) et pas une virgule (2,5). De mémoire, ça merde à l'import dans MySQL. Evite aussi les formats anglais (ex : 1 236.20) et autres formulations (1.236,20).

Vu que je passe pas mal de temps à parser des fichiers de prix qui viennent de différentes sources, d'expérience, je te conseil :
- soit de tester le format de ces chiffres avant l'injection dans la BDD (en PHP ou dans le langage de script que tu utilise)
- soit de bien normaliser les chiffres dans un tableur du style open office.

Si tu ne fais que cet import là et que tu n'a pas trop de mise à jour régulières à faire, oubli ce que je viens d'écrire.

 

[jcaron]

Attention, les nombres flottants ont des effets pervers (liés au stockage en base 2 alors que nous travaillons en base 10). Si tu dois absolument conserver ta valeur exactement telle quelle (et pas à peu près pareille), et que le nombre de décimales est constant (par exemple des prix avec toujours 2 décimales), il vaut mieux stocker ça sous forme d'entiers (après avoir multiplié ça par 100 dans l'exemple donné).

Sinon tu risques d'avoir des surprises, en particulier si après tu fais des opérations, même simples, sur ces nombres.

Jacques.

 

[milkiway]

Ah bon mais quel genre de surprises?et stocker sous forme de texte?

 

[Seb's]

Je pense que les surprises sont sur des précisions d'opérations arithmétiques.

Par exemple, en float, double, etc., on peut se retrouver avec l'opération 10 / 2 * 2 = 9.99999.

C'est pour ce genre de cas que les langages ont introduit des types décimaux, destinés à la base 10 spécifiquement.
Le stockage en entier est une solution, mais implique des opérations fréquentes (multiplication et division avant stockage et après récupération) qui au final s'avèrent coûteuses.

Personnellement, j'utilise le type DECIMAL (DECIMAL(30, 15), par exemple). Il me semble qu'il mange un peu en place dans la BD, mais est fait pour ce genre de cas, non ?

 

[jcaron]

Ben le truc c'est qu'il n'y a pas que la bdd qui pose problème, et comme la plupart des langages n'ont que les types entier ou flottant quand il s'agit de faire des calculs (et donc un "decimal" SQL sera converti en flottant en C, perl, php, JS, etc.), il vaut mieux qu'ils restent sous forme d'entiers en permanence. Effectivement ça oblige à faire une multiplication à la saisie et une division à l'affichage, mais tous le reste du temps tu le laisses en l'état (en gros, si tu manipules des montants en euros par exemple, tu les convertis illico en centimes, et tu les traites uniquement comme ça, sauf à l'affichage).

Jacques.

 

[milkiway]

En même temps je ne stocke que des données simples sur lesquelles je ne fais pas de traitement particulier.
Par exemple une consommation (5.8l/100km) ou un chrono 0 à 100 en 28.3 que je convertis en 28s3 (je remplace le point par un "s").

Merci pour les réponses en tout cas.

 

[blman]

Merci jacques pour ce petit cours, je viens d'apprendre quelquechose là.

 

[jcaron]

Effectivement vu ton application ce n'est pas très important. Là où c'est vraiment gênant c'est quand on essaie de stocker des montants, et qu'on finit par se retrouver avec des centimes en plus ou en moins quand on additionne ou soustrait plusieurs nombres.

Jacques.