Forums PostgreSQL.fr

Alain V.

Membre

[Résolu] Du bon usage de NUMERIC quand sa valeur attent d'être connue.

Bonjour le forum,

J'ai compris qu'un champs NUMERIC ne peux pas avoir de valeur nulle.
Quelle est donc la bonne pratique pour définir un tel champs lorsque sa
valeur sera connue après l'insertion d'un tuple?

Voici un exemple fictif basé sur le coût de sortie de stock d'un
produit.

-- DROP TABLE sortie_stock;
CREATE TABLE sortie_stock (
produit CHARACTER VARYING(8),
pu_vente NUMERIC(5,2),
taxe_douane NUMERIC(5,2)
);
COPY sortie_stock(
produit,
pu_vente,
taxe_douane) FROM stdin;
carottes    50    0
\.

Lorsque les carottes sortent du stock on connaît leur prix de vente mais
on ne connais pas encore le coût du dédouanement pourtant celui-ci est
un élément des charges.

La solution que j'image c'est de mettre la colonne "taxe_douane" dans
une table séparée. Dans ce cas seules les valeurs douanières déjà
connues y seront présentes. Dans cette table séparée, je n'aurai donc
que des tuples contenant des valeurs déjà connues.

Est-ce la bonne pratique ou est-ce qu'il y a une pratique mieux adaptée
pour définir un champs NUMERIC dont on ne connaît pas encore la valeur
mais dont on est sûr que plus tard il sera différent de 0?

Je vous remercie par avance.

Dernière modification par Alain V. (Aujourd'hui 08:46:23)

pifor

Membre

Re : [Résolu] Du bon usage de NUMERIC quand sa valeur attent d'être connue.

En général dans une base de données relationnelle, le fait qu'une colonne puisse avoir une valeur nulle ne dépend pas du type de la colonne mais de la présence d'une contrainte NOT NULL ou éventuellement d'un trigger.

Si la colonne n'a aucune contraite alors la valeur nulle est autorisée.

Exemple en 15.13:

select version();
                                                 version                        
                          
--------------------------------------------------------------------------------
--------------------------
 PostgreSQL 15.13 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 8.5.0 20210514 (
Red Hat 8.5.0-26), 64-bit
(1 row)

create table tn(n numeric(5,2));
CREATE TABLE
insert into tn values(null);
INSERT 0 1
Null display is "NULL".
select * from tn;
  n   
------
 NULL
(1 row)

select * from tn where n is null;
  n   
------
 NULL
(1 row)

Précisez votre version de PostgreSQL et la présence éventuelle d'un trigger ou d'une extension qui changerait le comportement de PG.

Dernière modification par pifor (Hier 19:29:49)

---

Pierre

Alain V.

Membre

Re : [Résolu] Du bon usage de NUMERIC quand sa valeur attent d'être connue.

En suivant votre exemple, en mettant null dans un champ numeric, j'ai effectivement constaté qu'il était possible de remettre à plus tard la saisie d'une valeur différente de 0.

Votre exemple a mis en évidence l'erreur que je faisais. Au lieu de mettre "null" je mettais "\N" ce qui provoquait un message d'erreur.

C'est pour trouver une solution à cette erreur que mes recherches m'ont fait découvrir - sur ce même forum - le fait que Postgresql refusait une chaîne vide. D'où mon insistance à mettre un "0".
Lors de mes recherches j'avais dû mal interpréter ces deux posts:
https://forums.postgresql.fr/viewtopic.php?id=964

31/08/2010 16:19:56
Nous n'avons aucun souci sous MySQL, Oracle ou SQL Server pour insérer
une chaine vide dans un champ numerique, il n'y a que postgreSQL qui
nous pose ce probleme.

31/08/2010 17:07:00
Tout ça simplement pour dire que ce n'est pas parce que PostgreSQL
refuse que c'est de sa faute : il valide vos données.

Et pour répondre à vos questions :
- La colonne n'avait pas de contrainte NOT NULL
- La version de Postgresql :
PostgreSQL 13.21 (Debian 13.21-0+deb11u1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 10.2.1-6) 10.2.1 20210110, 64-bit
Quand à la présence d'un trigger ou d'une extension, ma connaissance sur Postgresql ne m'a pas encore fait aborder ces usages.

Je vous remercie pour votre réponse. Elle m'a permis de rectifier mon usage d'une valeur nulle.