9:46 a.m.
Salut les copains,
Je suis en train d'essayer d'utiliser Clearbricks pour un petit truc perso
qui inclus une gestion de prix. Vous utiliseriez quel type dans MySQL?
Quell taille ? Vous définiriez ça comment en dbschema Clearbricks?
J'accepte volontiers qu'on ne réponde pas à toutes les questions. Les
réponses aux questions MySQL m'aideraient déjà beaucoup.
xave
9:57 a.m.
Salut Xave,
sans tests, et en aveugle, je dirais qu'un type float fait le boulot. Non ?
Je définirais ça comme ça :
$s->ma_table
->prix('float',...
Nicolas
Le 12 mars 2014 09:46, xave <xave(a)xave.org> a écrit :
Salut les copains,
Je suis en train d'essayer d'utiliser Clearbricks pour un petit truc perso
qui inclus une gestion de prix. Vous utiliseriez quel type dans MySQL?
Quell taille ? Vous définiriez ça comment en dbschema Clearbricks?
J'accepte volontiers qu'on ne réponde pas à toutes les questions. Les
réponses aux questions MySQL m'aideraient déjà beaucoup.
xave
--
Dev mailing list - Dev(a)list.dotclear.org - http://ml.dotclear.org/listinfo/dev
10 a.m.
Le 12 mars 2014 09:57, Nicolas <nikrou77(a)gmail.com> a écrit :
Salut Xave,
sans tests, et en aveugle, je dirais qu'un type float fait le boulot. Non ?
Je définirais ça comme ça :
$s->ma_table
->prix('float',...
Un type mysql DECIMAL ou NUMERIC serait à mon avis plus pertinent (entre
autres à cause des gestions d'arrondi sur les float). Toutefois ce type
n'est pas supporté par clearbricks...
--
Bruno
10:07 a.m.
Un type mysql DECIMAL ou NUMERIC serait à mon avis plus pertinent
(entre
autres à cause des gestions d'arrondi sur les float). Toutefois ce type
n'est pas supporté par clearbricks...
Je confirme que float, ça ne marche pas. Que Decimal, ça serait top,
mais qu'effectivement le "numeric" de dbstruct, s'il est très bien
pour du postgres, ne gère pas la taille pour MySQL. Il semblerait donc
soit que je l'ai dans le cul, soit que je doive hacker Clearbricks.
10:17 a.m.
Le 12 mars 2014 10:07, xave <xave(a)xave.org> a écrit :
> Un type mysql DECIMAL ou NUMERIC serait à mon avis plus
pertinent (entre
> autres à cause des gestions d'arrondi sur les float). Toutefois ce type
> n'est pas supporté par clearbricks...
Ou sinon tu triches : tu prends un type entier, et tu stocke tes montants
*100 en base :)
10:56 a.m.
2014-03-12 10:21 GMT+01:00 xave <xave(a)xave.org>:
> Ou sinon tu triches : tu prends un type entier, et tu stocke tes
montants
> *100 en base :)
Spas con, ça. ça ne correspond pas à ce que je voulais faire
(important d'un autre format en respectant les champs), mais c'est pas
con.
Dans mon travail (où je traite justement des transactions de paiement dans
diverses monnaies), les montants sont toujours stockés sur deux colonnes :
la première est un entier stockant le montant exprimé dans la plus petite
décimale de la monnaie (donc, un montant en centimes pour l'Euro par
exemple) et la deuxième colonne indique l'exposant de la monnaie (donc 2
pour l'Euro et 0 pour le Yen par exemple). Ainsi, la colonne exposant nous
dit précisément où poser la virgule lors de l'affichage ou d'échanges avec
d'autres systèmes, et on s'affranchit complètement des problèmes d'arrondis
qui pourraient surgir.
julien
8:28 a.m.
Commentaire du créateur de Clearbricks hier soir : "Ah ben non. J'ai
oublié. T'as qu'à le rajouter."
9:20 a.m.
Plop
J'arrive peut-être un peu tard, mais j'avais fait un plugin qui
s'occupait d'une gestion de prix pour un camping, et j'enregistrais
les valeurs dans un champ de type real
Je ne sais pas en revanche si ça marche sous PotGreSQL, si tu veux je
t'envoie mon fichier d'install qui crée les tables ?
La bise
Philippe
2014-03-13 8:28 GMT+01:00 xave <xave(a)xave.org>:
Commentaire du créateur de Clearbricks hier soir : "Ah ben non.
J'ai
oublié. T'as qu'à le rajouter."
--
Dev mailing list - Dev(a)list.dotclear.org - http://ml.dotclear.org/listinfo/dev
9:32 a.m.
philippe(a)dissitou.org a écrit :
Plop
J'arrive peut-être un peu tard, mais j'avais fait un plugin qui
s'occupait d'une gestion de prix pour un camping, et j'enregistrais
les valeurs dans un champ de type real
Je ne sais pas en revanche si ça marche sous PotGreSQL, si tu veux je
t'envoie mon fichier d'install qui crée les tables ?
Si j’en crois la doc,
http://docs.postgresql.fr/9.2/datatype.html
real float4 Nombre à virgule flottante de simple précision (sur
quatre octets)
Donc cela ne doit pas poser de problème !
Bonne journée,
Laurent.
11 a.m.
J'arrive peut-être un peu tard, mais j'avais fait un plugin
qui
s'occupait d'une gestion de prix pour un camping, et j'enregistrais
les valeurs dans un champ de type real
Pareil, on se retrouve avec des imprécisions (quand tu veux
additionner des milliers d'opérations, ça peut poser problème). Je
n'ai pas de problème avec Postgres, par contre, où le type "numeric"
est parfait. Je ne cherche pas non plus une solution de contournement,
je peux en trouver une facilement. Je voulais juste vérifier que je ne
me trompais pas : il y a un problème dans Clearbricks avec la gestion
de certains types dans MySQL. Mais merci.
11:08 a.m.
Le 13 mars 2014 11:00, xave <xave(a)xave.org> a écrit :
> J'arrive peut-être un peu tard, mais j'avais fait un
plugin qui
> s'occupait d'une gestion de prix pour un camping, et j'enregistrais
> les valeurs dans un champ de type real
Pareil, on se retrouve avec des imprécisions (quand tu veux
additionner des milliers d'opérations, ça peut poser problème). Je
n'ai pas de problème avec Postgres, par contre, où le type "numeric"
est parfait. Je ne cherche pas non plus une solution de contournement,
je peux en trouver une facilement. Je voulais juste vérifier que je ne
me trompais pas : il y a un problème dans Clearbricks avec la gestion
de certains types dans MySQL. Mais merci.
Le type numeric de mysql semble exister, et équivalent à decimal, il y a
peut-être juste un iota à faire coté CB pour le supporter :)
--
Bruno
1:48 p.m.
Le type numeric de mysql semble exister, et équivalent à decimal, il
y a
peut-être juste un iota à faire coté CB pour le supporter :)
Le "numeric" de mysql, c'est effectivement un alias du "decimal'.
La
différence avec le "numeric" de Postgres, c'est que postgres se
démerde tout seul pour la taille, alors qu'elle doit être explicite
pour mysql. Explicite *et* à deux chiffres (taille totale+précision).
Du coup, c'est un rien plus qu'un iota, puisque tout dbstruct est codé
pour une taille exprimée en une valeur, pas deux.
1:52 p.m.
Le "numeric" de mysql, c'est effectivement un alias du "decimal'.
La
différence avec le "numeric" de Postgres, c'est que postgres se
démerde tout seul pour la taille, alors qu'elle doit être
explicite
pour mysql. Explicite *et* à deux chiffres (taille totale+précision).
Du coup, c'est un rien plus qu'un iota, puisque tout dbstruct est codé
pour une taille exprimée en une valeur, pas deux.
Ah ué, vu comme ça, MySQL c'est (encore une fois) tout pourri... :)
--
Bruno
2:48 p.m.
Le 12/03/14 10:17, Bruno a écrit :
Ou sinon tu triches : tu prends un type entier, et tu stocke tes
montants
*100 en base :)
Je confirme avoir souvent entendu que c'était une bonne manière de faire
(mais je ne suis pas pro du truc).
Bàt
--
Pinkilla
pb(à)namok.be
http://pit.namok.be / http://blog.namok.be
3719
days inactive
3721
days old
15 comments
7 participants
participants (7)
-
Bruno -
Julien Mudry -
Laurent Wandrebeck -
Nicolas -
philippe＠dissitou.org -
Pinkilla -
xave