double precision mais pas de chiffres après la virgule

[mathieu_r]

Bonjour,


Je début sous Postgre

J'ai créé un champ rarete de type double precision

alter table releves add column rarete double precision

j'ai mis à jour cette table avec uen donnée de pourcentage mais la valeur retournée ne comporte pas de chiffres après la virgule.


ai-je choisi le bon type de données?

[punkoff]

bonjour,

cf la doc http://www.postgresql.org/docs/9.1/s...e-numeric.html

double precision c'est 15 decimal.

Maintenant avez-vous besoin de 15 décimales ?
Un numeric(2,X) où X est le nombre maximal souhaité, serai plus adéquate.

[mathieu_r]

si double precision permet d'afficher 15 décimales, pourquoi ne m'en affiche t il aucune?

j'ai créé une colonne de type numeric(2,2) pour 2 décimales (y a-t-il une écriture plus simple, d'ailleurs)

Code :

ALTER TABLE releves ADD COLUMN rarete numeric(2,2)

Au lancement de la requête

Code :

UPDATE releves SET rarete4 = 100 -(100*nbmaillestaxon/nbmaillesdep)

il me donne

Code :

1
2
3
4
5
6
7
8
9
10
ERREUR:  champ numérique en dehors des limites
DETAIL:  Un champ de précision 2 et d'échelle 2 doit être arrondi à une valeur
absolue inférieure à 1.
 
********** Erreur **********
 
ERREUR: champ numérique en dehors des limites
État SQL :22003
Détail :Un champ de précision 2 et d'échelle 2 doit être arrondi à une valeur
absolue inférieure à 1.

toute aide est la bienvenue.

Désolé pour ces questions qui peuvent paraître évidentes pour les utilisateurs avancés.

[punkoff]

Bonjour,


Alors en fait là pgsql va interpréter votre demande assez ...spécialement.

Essyer ceci :

Code :

1
2
 
SELECT 40/567

=> 0

et maintenant :

Code :

1
2
 
SELECT 40.0/567.0

=> 0.07054673721340388007

que c'est-il passé ? dans le 1er cas il va caster votre résultat comme un integer.
Dans le 2eme cas, vu que l'on a mit ".0" il va caster le résultat comme un numeric.

Donc soit vous forcez la caste manuellement avec "CAST(mon_nombre as numeric)" soit vous rajoutez ".0".
Ensuite n'oubliez pas de round votre résultat sinon il y a des chances qu'il tronque tout simplement (je n'ai pas testé, donc à vérifier).

Ce qui nous donne au final :

Code :

1
2
 
UPDATE releves SET rarete4 = 100.0 -(100.0*nbmaillestaxon/nbmaillesdep)

Ceci renvera un résultat de type numeric donc avec une vigule

j'ai créé une colonne de type numeric(2,2) pour 2 décimales (y a-t-il une écriture plus simple, d'ailleurs)

Non il n'y a pas plus simple comme écriture.

Par contre vous pouvez créer un domain qui sera de type numeric(2, 2), et ce domain sera ré-utilisable de partout dans votre schéma.

Code :

1
2
3
 
CREATE DOMAIN d_pourcentage
   AS numeric(2,2);

Code :

1
2
 
CREATE TABLE t_pct (mon_nbr d_pourcentage);

[mathieu_r]

merci beaucoup pour toutes ces informations. c'est nickel!

j'en apprends, des choses, d'un seul coup

[SQLpro]

Si vous ne voulez pas de décimale, pourquoi ne pas travailler avec les types entiers INT ( =/ - 2 milliards) ou BIGINT (+/-2^63) ???

A +

[JeitEmgie]

Envoyé par mathieu_r

si double precision permet d'afficher 15 décimales, pourquoi ne m'en affiche t il aucune?

j'ai créé une colonne de type numeric(2,2) pour 2 décimales (y a-t-il une écriture plus simple, d'ailleurs)

NB
numeric(2,2) ne permet pas de stocker des nombres de 0.00 à 1.00 mais de 0.00 à 0.99 : 100% (1.00) ne peut pas être exprimé dans ce format.

maintenant si ce que vous voulez stocker ce sont des % [0.; 100.0] avec une précision de 2 décimales c'est numeric(5,2) que vous devez utiliser, éventuellement avec une contrainte "check(rarete >= 0.0 and rarete <= 100.0)".

(ou utiliser un autre format numérique que "numeric(precision, scale)" …)

[CetTer]

Le casting peut être aussi utilisé sous cette forme plus courte pour forcer la précision vers les décimales.

Code :

INSERT INTO test_precision (valeur) VALUES (15/100::double precision );

Insère bien 0.15.

L'avantage est que la valeur entrée par l'utilisateur n'est pas altérée et que le CAST n'est indiqué qu'une seule fois pour toute l'expression. Utile si un script effectue l'insertion. C'est vrai que ce n'est un comportement pas très consistant, PostgreSQL pourrait caster par défaut en écriture dans le type du champs...