Discussion :

[Sve@r]

Bonjour à tous

J'ai un petit soucis de requête PostgreSQL. J'ai créé un type énuméré. Style CREATE TYPE t_couleur AS ENUM ('trèfle', 'carreau', 'coeur', 'pique')

D'un autre coté je développe une IHM où je vais offrir à l'utilisateur le choix de la couleur dans un menu déroulant. Je voudrais donc pouvoir récupérer mes 4 valeurs "trèfle", "carreau", ... pour les insérer dans le menu déroulant (et donc ne pas le faire en dur dans mon code quoi).

Or là, j'arrive à un blocage. Pas moyen de trouver la bonne requête SQL qui me renvoie mes 4 items.

Si quelqu'un peut m'aider...

Merci

[CinePhil]

Je ne sais pas si c'est pareil en Postgresql mais quand utilise le type ENUM en MySQL, ce qui est stocké en BDD, c'est l'indice du tableau de valeurs possibles, donc un simple entier.

Essaie plutôt de créer une table de référence avec tes 4 couleurs et fais une jointure dessus.

[estofilo]

Il faut trouver le type par son nom dans la table pg_type et joindre avec pg_enum, en triant éventuellement par l'OID de pg_enum si on veut récupérer le même ordre qu'à la déclaration.

[Sve@r]

Je ne sais pas si c'est pareil en Postgresql mais quand utilise le type ENUM en MySQL, ce qui est stocké en BDD, c'est l'indice du tableau de valeurs possibles, donc un simple entier.

Comme en C donc. Peut-être que c'est la même chose en PostgreSQL. Mais même si c'est le cas, alors ça ne sera pas plus dégradant en terme de perfs ou de de requêtes que passer par le lien dont tu parles (avec clef externe + contrainte d'intégrité référentielle et tout le toutim)

Essaie plutôt de créer une table de référence avec tes 4 couleurs et fais une jointure dessus.

Ben en fait, c'est ce que je fais de façon générale. J'ai ce que j'appelle des tables "catalogue". J'avais d'ailleurs prévu pour ça aussi un catalogue.
Mais conceptuellement, je différencie 3 choses
1) ce qui évolue très souvent.
Par exemple si je dois faire un lien entre un livre et son auteur, je créerai une table "livre" et une table "auteur". Et les deux tables pourront évoluer de façon indépendante et relativement souvent selon que l'utilisateur veut rajouter des auteurs ou des livres. Mais en conservant l'intégrité.

2) ce qui évolue très peu mais qui peut quand-même évoluer
Par exemple si je dois faire un lien entre un client et son titre (M., Mme, Mlle) ben je créerai alors dans ce cas là une table que j'appelle "catalogue" style "_cat_titre". Cette table pourra évoluer (on pourra rajouter éventuellement "Docteur" ou "Professeur" ou "Maitre" ou ...) mais cette évolution est plus rare. Et il est probable que je ne créerai pas d'IHM pour ça, laissant le soin de passer par pgadmin ou mieux, le mettre en dur dans le script sql de création de la bdd.

3) ce qui ne peut catégoriquement pas évoluer => typique des couleurs. Et là, je trouvais alors dommage de créer une table juste pour ça avec, comme je l'ai dit, les contraintes d'intégrité, les droits de select et tout et tout alors qu'un simple enum suffit. Mais si je peux pas faire autrement alors je le ferai (pour l'instant j'ai d'ailleurs les deux solutions d'implémentées avec ma table qui contient un enum et aussi une clef sur le catalogue des couleurs). Ainsi, si je peux passer définitivement à l'enum les modifs seront minimes. Et si je dois passer définitivement au catalogue alors me suffit de supprimer la colonne enum.

Il faut trouver le type par son nom dans la table pg_type et joindre avec pg_enum, en triant éventuellement par l'OID de pg_enum si on veut récupérer le même ordre qu'à la déclaration.

Ca c'est joli. Je m'étais effectivement dit que ça devait être stocké quelque part dans les pg_truc mais là, même si j'arrive à me dépatouiller assez avec ces tables systèmes pour lister les tables de ma bdd et compter leur nb de lignes, je suis pas encore assez au point pour trouver tout seul. Merci à toi pour ces infos...