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...:)
Version imprimable
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...:)
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).:cry:Citation:
Envoyé par bob633
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.
Pouviez vous me rendre cela plus claire ?Citation:
Envoyé par 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.
Cdlt.Code:$nValeurHtml = devTransformationMonetaire($aResultat['nom_champ']);
Bonjour,
Si c le cas d'un nombre avec des milliards, le meilleur type est REAL.
Bonne chance :)
Oui certaines valeurs se chiffres à des milliards de francs CFA...Citation:
Envoyé par ahmedious
Donc le type REAL reste approprié ?
Je me pose aussi la question pourquoi typer en réel ? Pourquoi ne pas favoriser un bigint ?Citation:
Envoyé par ahmedious
Juste parce que les centimes existent dans la monnaie et Bigint est un entier (gros entier).Citation:
Je me pose aussi la question pourquoi typer en réel ? Pourquoi ne pas favoriser un bigint ?
Je m'en serais douté :) Mais je parlais spécifiquement de la réponse d'Ahmedious
Du coup ouai c'est plus logique x)Citation:
Si c le cas d'un nombre avec des milliards
Le type approprié pour les données monétaires et qui permet de faire des calculs exacts est DECIMAL.
+1Citation:
Envoyé par CinePhil
Ou BIGINT si tu stockes des centimes ;)
Que veut dire stocker les centimes?Citation:
Envoyé par zeyr2mejetrem
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.Citation:
Envoyé par okoweb
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 ??:D
J'ai opté pour bigint qui me permet de stocker des centaines de milliards. mais autre de bien je suis prenant.
Merci à vous tous...:ccool:
A ton service. :ccool:Citation:
Envoyé par okoweb
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:Citation:
Envoyé par okoweb
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 :ccool:
Bonne chance :)
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.Citation:
Envoyé par ahmedious
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 ;)
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.Citation:
Envoyé par zeyr2mejetrem
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 ;).
Non c pas vrai, un type qui est flottant même avec un seul nombre après la virgule c'est un DECIMAL :mouarf:Citation:
Envoyé par zeyr2mejetrem
En plus et c'est toujours le cas pour un nombre monétaire soit sur mysql ou d'autres SGBD comme oracle 8O.
Il n'y a pas de travail supplémentaire si tu parles toujours en chiffre rond (en centimes, par ex.)Citation:
Envoyé par ahmedious
Par définition, un nombre flottant est un nombre pour lequel le nombre de décimales peut varier.Citation:
Non c pas vrai, un type qui est flottant même avec un seul nombre après la virgule c'est un DECIMAL :mouarf:
En monétaire tes nombres ne sont pas des flottants car ils ont toujours 2 décimales (dans un organisme bancaire, si tu écris 15 au lieu de 15,00 tu peux te prendre une chasse. Je sais, j'ai donné).
Je suis bien d'accord que tu peux stocker tes montants sous la forme DECIMAL(M,D) sauf que
- Tu mets quoi en M ? Si tu mets trop petit, t'es rapidement embêté. Si tu mets trop grand tu stockes des bits vides en base
- Quand tu exécutes des traitements bancaires, les virgules dans les montants c'est le meilleur moyen de se prendre les pieds dans le tapis.
Evitons les phrases commençant par "C'est toujours comme ça". Dans les banques où j'ai travaillé, la plupart du temps les montants étaient stockés en entier (pas toujours mais souvent).Citation:
En plus et c'est toujours le cas pour un nombre monétaire soit sur mysql ou d'autres SGBD comme oracle 8O.
Après il est vrai que selon l'application du site que l'on code on peut être plus ou moins "borné" :)