Discussion :

[okoweb]

Bonjour,
Tout est dans le titre, mais en somme je souhaite dans une table stocker des valeurs monétaires. Quel type de champ choisir dans MySQL. Les valeurs pourront être des milliards de franc CFA.

Merci d'avance...

[bob633]

Pourquoi pas tout simplement un int ?

Tu as un traitement spécial sur ces valeurs ?

[okoweb]

Pourquoi pas tout simplement un int ?

Tu as un traitement spécial sur ces valeurs ?

Justement des traitements arithmétiques ordinaires (addition, soustraction, division et multiplication).

[cycyand1]

Bonjour okoweb,

Il n'existe pas de type monétaires dans les tables MySQL car suivant où tu es l'affichage n'est pas le même.
Pour les connaitre ouvre un fichier excel et clique droit->format de cellule.
Bref, je te conseil de prendre le type "float" ou "double" suivant la valeur maximale qui tu peux atteindre : http://http://www.vulgarisation-info...es-donnees.php et fait la transformation de la donnée seulement à l'affichage, ça t'évitera de faire de multiple transformations si tu doit faire des calculs avec cette données. De plus dissocie les valeurs d'affichage et celles que tu récupères depuis la base.


Cdlt.

[okoweb]

...
fait la transformation de la donnée seulement à l'affichage, ça t'évitera de faire de multiple transformations si tu doit faire des calculs avec cette données. De plus dissocie les valeurs d'affichage et celles que tu récupères depuis la base.
Cdlt.

Pouviez vous me rendre cela plus claire ?

[cycyand1]

okoweb,
Concrètement :
$nValeurHtml = valeur que tu vas afficher à l'ecran.
devTransformationMonetaire() : fonction qui te retourne la transformation monétaire que tu souhaites.
$aResultat['nom_champ'] : valeur extraite de la requête MySQL

Tu appelles la fonction sur chaque champ où tu dois effectuer la transformation monétaire.

Code :

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

$nValeurHtml = devTransformationMonetaire($aResultat['nom_champ']);

Cdlt.

[ahmedious]

Bonjour,

Si c le cas d'un nombre avec des milliards, le meilleur type est REAL.

Bonne chance

[okoweb]

Si c le cas d'un nombre avec des milliards, le meilleur type est REAL.

Oui certaines valeurs se chiffres à des milliards de francs CFA...

Donc le type REAL reste approprié ?

[gwharl]

Si c le cas d'un nombre avec des milliards, le meilleur type est REAL.

Je me pose aussi la question pourquoi typer en réel ? Pourquoi ne pas favoriser un bigint ?

[cycyand1]

Je me pose aussi la question pourquoi typer en réel ? Pourquoi ne pas favoriser un bigint ?

Juste parce que les centimes existent dans la monnaie et Bigint est un entier (gros entier).

[gwharl]

Je m'en serais douté Mais je parlais spécifiquement de la réponse d'Ahmedious

Si c le cas d'un nombre avec des milliards

Du coup ouai c'est plus logique x)

[CinePhil]

Le type approprié pour les données monétaires et qui permet de faire des calculs exacts est DECIMAL.

[zeyr2mejetrem]

Le type approprié pour les données monétaires et qui permet de faire des calculs exacts est DECIMAL.

+1
Ou BIGINT si tu stockes des centimes

[okoweb]

BIGINT si tu stockes des centimes

Que veut dire stocker les centimes?

[zeyr2mejetrem]

Que veut dire stocker les centimes?

Au lieu de stocker dans ta base tes sommes sous la forme 1500 000,50 CFA en Decimal , ce qui peut être dangereux dans la mesure où rien dans l'infra ne t'empêches de stocker 1520, 156666666 CFA ce qui ne signifie rien en soi, tu stockes 150000050 soit des centimes de francs CFA en BIGINT. Ainsi tu es sûr de ne pas stocker des millimes par accident.

De plus tu peux créer un trigger qui va faire ton arrondi.
Ainsi si tu calcules un intérêt financier à 3,5% par exemple sur 125 CFA tu obtiens
0.035 * 12500 = 437,5 ==> (en entier arrondi) 438 centimes de CFA ==> 4,38 CFA

alors qu'en décimal tu aurais stocké 4,375 CFA or je suis pas spécialiste du CFA mais il me semble pas qu'il y ait de pièce de 0,005 CFA ??

[okoweb]

J'ai opté pour bigint qui me permet de stocker des centaines de milliards. mais autre de bien je suis prenant.

Merci à vous tous...

[zeyr2mejetrem]

J'ai opté pour bigint qui me permet de stocker des centaines de milliards. mais autre de bien je suis prenant.

Merci à vous tous...

A ton service.

[ahmedious]

Oui certaines valeurs se chiffres à des milliards de francs CFA...

Donc le type REAL reste approprié ?

Pour un champ monétaire, il doit y avoir des décimales et donc le BIGINT n'est pas l'approprié, voici un détail technique de:

Le BIGINT n'est pas flottant.

BIGINT[(n)] [UNSIGNED][ZEROFILL]
Entier (sur 8 octets) de – 9 223 372 036 854 775 808 à
9 223 372 036 854 775 807 signé, 0 à
18 446 744 073 709 551 615 non signé.


Le REAL est l'alias de DOUBLE avec 15 en décimales et pas 30 comme le DECIMAL.

DOUBLE[(n[,p])] [UNSIGNED][ZEROFILL]
Flottant (sur 8 octets) p désigne la précision double (jusqu’à 15
décimales) de -1.7 10+308 à -2.2 10-308, 0, signé, et de 2.2 10-308
à 1.7 10+308 non signé.

DECIMAL[(n[,p])] [UNSIGNED][ZEROFILL]
Décimal à virgule fixe, p désigne la précision (nombre de chiffres
après la virgule, maximum 30). Par défaut n vaut 10, p vaut 0.

Il y a aussi le FLOAT:

FLOAT[(n[,p])] [UNSIGNED][ZEROFILL]
Flottant (de 4 à 8 octets) p désigne la précision simple (jusqu’à
7décimales) de -3.4 10+38 à -1.1 10-38, 0, signé, et de 1.1 10-38 à
3.4 10+38 non signé.

Voilà, j'espère que cette explication technique pourra vous aider

Bonne chance

[zeyr2mejetrem]

Pour un champ monétaire, il doit y avoir des décimales et donc le BIGINT n'est pas l'approprié, voici un détail technique de:

Le BIGINT n'est pas flottant.

BIGINT[(n)] [UNSIGNED][ZEROFILL]
Entier (sur 8 octets) de – 9 223 372 036 854 775 808 à
9 223 372 036 854 775 807 signé, 0 à
18 446 744 073 709 551 615 non signé.

Si tu lis les précédents post, j'explique qu'un monétaire n'est PAS un décimal à proprement parler puisqu'il ne peut pas avoir plus de 2 décimales.

Par conséquent une somme d'argent est un chiffre ENTIER de centimes.
Et comme ton rappel technique très utile le dis tu peux donc stocker des montants allant de

-92 233 720 368 547 758,08 CFA
à 92 233 720 368 547 758,08 CFA

ou pour les valeurs absolues (ex: prix à l'unité)
184 467 440 737 095 516,15 CFA

[ahmedious]

Au lieu de stocker dans ta base tes sommes sous la forme 1500 000,50 CFA en Decimal , ce qui peut être dangereux dans la mesure où rien dans l'infra ne t'empêches de stocker 1520, 156666666 CFA ce qui ne signifie rien en soi, tu stockes 150000050 soit des centimes de francs CFA en BIGINT. Ainsi tu es sûr de ne pas stocker des millimes par accident.

De plus tu peux créer un trigger qui va faire ton arrondi.
Ainsi si tu calcules un intérêt financier à 3,5% par exemple sur 125 CFA tu obtiens
0.035 * 12500 = 437,5 ==> (en entier arrondi) 438 centimes de CFA ==> 4,38 CFA

alors qu'en décimal tu aurais stocké 4,375 CFA or je suis pas spécialiste du CFA mais il me semble pas qu'il y ait de pièce de 0,005 CFA ??

Je vois pas pourquoi tu parles du danger puisque on peut maîtriser le nombre de décimales, et en plus tu rajoutes du travail gratuit.
Avec le DOUBLE[(n[,p])] où p désigne la précision double, on peut y mettre 2 et donc pas de risque au lieu d'avoir le fardeau de diviser toujours par 100 .

j'explique qu'un monétaire n'est PAS un décimal à proprement parler puisqu'il ne peut pas avoir plus de 2 décimales

Non c pas vrai, un type qui est flottant même avec un seul nombre après la virgule c'est un DECIMAL

En plus et c'est toujours le cas pour un nombre monétaire soit sur mysql ou d'autres SGBD comme oracle .