[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Phpcompta-contrib] Longueur de champs
From: |
Dany De Bontridder |
Subject: |
Re: [Phpcompta-contrib] Longueur de champs |
Date: |
Tue, 16 May 2006 21:36:52 +0200 |
User-agent: |
KMail/1.8.2 |
On Tuesday 16 May 2006 21:00, herve couvelard wrote:
> Dany De Bontridder a écrit :
> > On Monday 15 May 2006 22:38, Yannick Warnier wrote:
> > (...)
> > L'indexation des varchar n'est pas si pénalisant. Un char c'est exclu. Je
> > crois que decimal (20) est le meilleur choix (en plus c'est ansi sql/92
> > comme numeric). Hervé, qu'en penses-tu ?
> >
> > D.
>
> Parfois j'ai un peu du mal à comprendre le cheminement. Pourquoi mettre
> une valeur numériques dans un varchar et pourquoi l'indexer ?
Pour rappel, c'était stan qui utilisait des postes comptables dont la longueur
était supérieur à ce qu'int permet. (tmp_pcmn.pcm_val)
> A quoi peut servir d'indexer une valeur d'une écriture comptable ?
Cette valeur est indexé puisque c'est une PK ;-) Donc unique et non nul
> Juste une question idiote, pourquoi les valeurs comptables ne sont pas
> enregistrées en centimes ( cad sans virgules ?) cela éviterait plein de
> problèmes d'arrondis.
Ben justement, c'est pour ça qu'on utilise les numeric : quand l'opération est
enregistrée il n'y a plus de problème d'arrondi contrairement à un float ou à
n'importe quelle autre type, si tu utilises int (en multipliant par 100) pour
éliminer les valeurs décimales est exactement la même chose, qu'utiliser
numeric(10,2) (ou decimal(10,2)) tu vois ça sert d'être marié avec les bases
de données ;-)
Les problèmes d'arrondi que j'avais sont en fait du à PHP qui calcule en
float :-( Ces calculs devraient être refaits avec une biblio mathematique.
D.