Pour un petit site de vente de musique en ligne je vais stocker le prix
des articles dans la table produits.
En fait le prix sera peut-être déporté dans une table "catégories de
prix", mais quelle que soit la façon je voudrais savoir quelle est la
meilleure façon de stocker les prix dans MySQL : type de champ,
char/varchar, INT ou FLOAT...?
Il s'agit de prix en Euro, qui peuvent prendre n'importe quelle valeur :
10 €, 19,99 €, etc.
Le site pourrait proposer un outil de conversion des devises. Dans ce
cas d'après votre expérience, y a-t-il des précaution à prendre, vaut-il
mieux stocker les prix en euros ou en dollars...
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Sébastien
Patrick Mevzek a écrit :
Le Tue, 22 Nov 2005 12:09:58 +0100, Sébastien a écrit : Pas un champ texte, et pas un float à cause des erreurs d'arrondis. Donc un int, en multipliant tous les prix par 100 si vous avez 2 chiffres après la virgule, ou numeric(6,2) ce qui signifie nombre de 6 chiffres dont 2 après la virgule, en précision infinie.
J'ai choisi decimal(6,2)
Vous vendez depuis où ? La France ? Donc les prix sont en euros et vous les stockez ainsi. Rien d'autre dans la base, puisque toutes les autres monnaies sont variables. Ce qui ne vous empêche pas au moment où quelqu'un passe sur votre site, de proposer une conversion, uniquement à l'affichage donc.
Merci !
Patrick Mevzek a écrit :
Le Tue, 22 Nov 2005 12:09:58 +0100, Sébastien a écrit :
Pas un champ texte, et pas un float à cause des erreurs d'arrondis.
Donc un int, en multipliant tous les prix par 100 si vous avez 2 chiffres
après la virgule, ou numeric(6,2) ce qui signifie nombre de 6 chiffres
dont 2 après la virgule, en précision infinie.
J'ai choisi decimal(6,2)
Vous vendez depuis où ? La France ? Donc les prix sont en euros et vous
les stockez ainsi. Rien d'autre dans la base, puisque toutes les autres
monnaies sont variables. Ce qui ne vous empêche pas au moment où
quelqu'un passe sur votre site, de proposer une conversion, uniquement à
l'affichage donc.
Le Tue, 22 Nov 2005 12:09:58 +0100, Sébastien a écrit : Pas un champ texte, et pas un float à cause des erreurs d'arrondis. Donc un int, en multipliant tous les prix par 100 si vous avez 2 chiffres après la virgule, ou numeric(6,2) ce qui signifie nombre de 6 chiffres dont 2 après la virgule, en précision infinie.
J'ai choisi decimal(6,2)
Vous vendez depuis où ? La France ? Donc les prix sont en euros et vous les stockez ainsi. Rien d'autre dans la base, puisque toutes les autres monnaies sont variables. Ce qui ne vous empêche pas au moment où quelqu'un passe sur votre site, de proposer une conversion, uniquement à l'affichage donc.
Merci !
Myna
Patrick Mevzek wrote:
Le Tue, 22 Nov 2005 12:09:58 +0100, Sébastien a écrit :
quelle est la meilleure façon de stocker les prix dans MySQL : type de champ, char/varchar, INT ou FLOAT...?
Pas un champ texte, et pas un float à cause des erreurs d'arrondis. Donc un int, en multipliant tous les prix par 100 si vous avez 2 chiffres après la virgule, ou numeric(6,2) ce qui signifie nombre de 6 chiffres dont 2 après la virgule, en précision infinie.
Bonjour,
J'ai une question sur ce thème. Je dois également stocker des prix dans une base. Le problème vient de la tva.
A partir d'un prix Hors Taxe en decimal(6,2) je tombe parfois sur des ttc à x chiffres après la virgule, et se repose alors le probleme des arrondis. Comment le gérer ? Vaut-il mieux utiliser un type plus précis genre decimal(6,4) pour tomber sur des prix TTC ok à 2 chiffres ou rester en decimal(6,2) et jouer sur les arrondis ?
Myna
Patrick Mevzek wrote:
Le Tue, 22 Nov 2005 12:09:58 +0100, Sébastien a écrit :
quelle est la
meilleure façon de stocker les prix dans MySQL : type de champ,
char/varchar, INT ou FLOAT...?
Pas un champ texte, et pas un float à cause des erreurs d'arrondis.
Donc un int, en multipliant tous les prix par 100 si vous avez 2 chiffres
après la virgule, ou numeric(6,2) ce qui signifie nombre de 6 chiffres
dont 2 après la virgule, en précision infinie.
Bonjour,
J'ai une question sur ce thème.
Je dois également stocker des prix dans une base. Le problème vient de
la tva.
A partir d'un prix Hors Taxe en decimal(6,2) je tombe parfois sur des
ttc à x chiffres après la virgule, et se repose alors le probleme des
arrondis. Comment le gérer ?
Vaut-il mieux utiliser un type plus précis genre decimal(6,4) pour
tomber sur des prix TTC ok à 2 chiffres ou rester en decimal(6,2) et
jouer sur les arrondis ?
Le Tue, 22 Nov 2005 12:09:58 +0100, Sébastien a écrit :
quelle est la meilleure façon de stocker les prix dans MySQL : type de champ, char/varchar, INT ou FLOAT...?
Pas un champ texte, et pas un float à cause des erreurs d'arrondis. Donc un int, en multipliant tous les prix par 100 si vous avez 2 chiffres après la virgule, ou numeric(6,2) ce qui signifie nombre de 6 chiffres dont 2 après la virgule, en précision infinie.
Bonjour,
J'ai une question sur ce thème. Je dois également stocker des prix dans une base. Le problème vient de la tva.
A partir d'un prix Hors Taxe en decimal(6,2) je tombe parfois sur des ttc à x chiffres après la virgule, et se repose alors le probleme des arrondis. Comment le gérer ? Vaut-il mieux utiliser un type plus précis genre decimal(6,4) pour tomber sur des prix TTC ok à 2 chiffres ou rester en decimal(6,2) et jouer sur les arrondis ?
Myna
pgulutzan
Sébastien wrote:
Patrick Mevzek a écrit : > Le Tue, 22 Nov 2005 12:09:58 +0100, Sébastien a écrit : > Pas un champ texte, et pas un float à cause des erreurs d'arrondis. > Donc un int, en multipliant tous les prix par 100 si vous avez 2 chiffr es > après la virgule, ou numeric(6,2) ce qui signifie nombre de 6 chiffres > dont 2 après la virgule, en précision infinie.
J'ai choisi decimal(6,2)
Dans ce cas, je recommande la nouvelle version MySQL 5.0 (ce n'est pas clair si vous l'utilisez déjà). Avec MySQL 5.0, les opérations avec DECIMAL ont une précision accrue. Voyez: http://dev.mysql.com/doc/refman/5.0/fr/precision-math.html
> Vous vendez depuis où ? La France ? Donc les prix sont en euros et vo us > les stockez ainsi. Rien d'autre dans la base, puisque toutes les autres > monnaies sont variables. Ce qui ne vous empêche pas au moment où > quelqu'un passe sur votre site, de proposer une conversion, uniquement à > l'affichage donc.
Merci !
Sébastien wrote:
Patrick Mevzek a écrit :
> Le Tue, 22 Nov 2005 12:09:58 +0100, Sébastien a écrit :
> Pas un champ texte, et pas un float à cause des erreurs d'arrondis.
> Donc un int, en multipliant tous les prix par 100 si vous avez 2 chiffr es
> après la virgule, ou numeric(6,2) ce qui signifie nombre de 6 chiffres
> dont 2 après la virgule, en précision infinie.
J'ai choisi decimal(6,2)
Dans ce cas, je recommande la nouvelle version MySQL 5.0
(ce n'est pas clair si vous l'utilisez déjà). Avec MySQL 5.0, les
opérations avec DECIMAL ont une précision accrue. Voyez:
http://dev.mysql.com/doc/refman/5.0/fr/precision-math.html
> Vous vendez depuis où ? La France ? Donc les prix sont en euros et vo us
> les stockez ainsi. Rien d'autre dans la base, puisque toutes les autres
> monnaies sont variables. Ce qui ne vous empêche pas au moment où
> quelqu'un passe sur votre site, de proposer une conversion, uniquement à
> l'affichage donc.
Patrick Mevzek a écrit : > Le Tue, 22 Nov 2005 12:09:58 +0100, Sébastien a écrit : > Pas un champ texte, et pas un float à cause des erreurs d'arrondis. > Donc un int, en multipliant tous les prix par 100 si vous avez 2 chiffr es > après la virgule, ou numeric(6,2) ce qui signifie nombre de 6 chiffres > dont 2 après la virgule, en précision infinie.
J'ai choisi decimal(6,2)
Dans ce cas, je recommande la nouvelle version MySQL 5.0 (ce n'est pas clair si vous l'utilisez déjà). Avec MySQL 5.0, les opérations avec DECIMAL ont une précision accrue. Voyez: http://dev.mysql.com/doc/refman/5.0/fr/precision-math.html
> Vous vendez depuis où ? La France ? Donc les prix sont en euros et vo us > les stockez ainsi. Rien d'autre dans la base, puisque toutes les autres > monnaies sont variables. Ce qui ne vous empêche pas au moment où > quelqu'un passe sur votre site, de proposer une conversion, uniquement à > l'affichage donc.
Merci !
nospam
Myna wrote:
A partir d'un prix Hors Taxe en decimal(6,2) je tombe parfois sur des ttc à x chiffres après la virgule, et se repose alors le probleme des arrondis. Comment le gérer ? Vaut-il mieux utiliser un type plus précis genre decimal(6,4) pour tomber sur des prix TTC ok à 2 chiffres ou rester en decimal(6,2) et jouer sur les arrondis ?
Cela pose un problème d'arrondir le prix TTC à deux chiffres après la virgule lors du calcul ?
-- Romuald Brunet, ICQ 33033393
Remplacez nospam par mon prénom pour me contacter par email
Myna <myna_31@hotmail.com> wrote:
A partir d'un prix Hors Taxe en decimal(6,2) je tombe parfois sur des
ttc à x chiffres après la virgule, et se repose alors le probleme des
arrondis. Comment le gérer ?
Vaut-il mieux utiliser un type plus précis genre decimal(6,4) pour
tomber sur des prix TTC ok à 2 chiffres ou rester en decimal(6,2) et
jouer sur les arrondis ?
Cela pose un problème d'arrondir le prix TTC à deux chiffres après la
virgule lors du calcul ?
--
Romuald Brunet, ICQ 33033393
Remplacez nospam par mon prénom pour me contacter par email
A partir d'un prix Hors Taxe en decimal(6,2) je tombe parfois sur des ttc à x chiffres après la virgule, et se repose alors le probleme des arrondis. Comment le gérer ? Vaut-il mieux utiliser un type plus précis genre decimal(6,4) pour tomber sur des prix TTC ok à 2 chiffres ou rester en decimal(6,2) et jouer sur les arrondis ?
Cela pose un problème d'arrondir le prix TTC à deux chiffres après la virgule lors du calcul ?
-- Romuald Brunet, ICQ 33033393
Remplacez nospam par mon prénom pour me contacter par email
