Annonce
L'appel à participation est ouvert jusqu'au 19 janvier 2025!
#1 Mon 08 September 2008 15:00
- NyPon
- Participant actif
- Date d'inscription: 3 Nov 2008
- Messages: 111
identifiant_geoconcept_postgres
Bonjour,
je suis en phase de test pour la connectivité géoconcept-postgresql.
j'arrive sans problème à afficher des données, mais dans ma base postgres, j'ai des identifiant relatifs.
je m'explique : j'ai une table "commune" avec comme identifiant "num_insee". celle-ci est liée à une table "section" qui à comme identifiant "num_insee, num_section" la clé étrangère de section vers commune est "num_insee" qui est aussi une partie de l'identifiant de "section".
pb : lorsque je configure le lien au type dans geoconcept, une seule clé primaire est proposée.
ainsi, si je veux selectionner juste les sections qui m'intéresse, je ne peux pas car "num_section" n'est pas unique. c'est "num_insee, num_section qui est unique".
il y a un bouton "config clé..." qui est proposé et on peut apparemment utiliser une fonction pour récupérer la valeur de la clé. savez vous si je peux récupérer le fait que ma clé est la concaténation des deux champs ???
avez-vous une solution ou des pistes ??
merci
Hors ligne
#2 Tue 09 September 2008 10:40
Re: identifiant_geoconcept_postgres
Bonjour,
Je ne pense pas que geoconcept sache se baser sur une clé "multi-champs".
Vous avez la possibilité de créer un champ qui sera la concaténation des 2 et ensuite l'utiliser dans géoconcept.
Vos num_section sont susceptible d'etre modifier ?
si oui, il serait préférable de ne pas l'utiliser comme idenfiant. Vous pouvez créer un champ ID unique indépendant incrémenté à partir du'un séquence ou d'un compteur quelconque.
Cordialement,
Fabrice
Hors ligne
#3 Tue 09 September 2008 11:13
- naman10
- Participant actif
- Date d'inscription: 7 Nov 2007
- Messages: 118
Re: identifiant_geoconcept_postgres
Sinon si je me souviens bien, postgresql contient un champ qui identifie chaque enregistrement par un numéro unique, peut être essayer de travailler avec ça...
bonne journée
Hors ligne
#4 Wed 10 September 2008 12:12
- NyPon
- Participant actif
- Date d'inscription: 3 Nov 2008
- Messages: 111
Re: identifiant_geoconcept_postgres
Bonjour,
merci de vos réponses,
j'ai effectivement essayé d'importer avec un champs unique auto incrémenté, que je ne définis pas comme clé unique dans postgres, mais défini en tant que clé dans geoconcept.
ça marche. mais j'aurais été intéressé par l'utilisation d'une clé multichamps.
visiblement ça ne fonctionne pas mais alors, à quoi sert l'option pour l'utilisation des fonctions pour récupérer les valeurs des clés dans la fenêtre "config clé..." ? quelqu'un connait-il le fonctionnement de cette option ?
je ne sais pas s'il y a une doc pour ça et où la trouver ?
j'ai aussi essayer de cocher l'option "compteur interne" mais lorsque je clique sur une section, il sélectionne toutes les sections de la région.
mes sections sont susceptibles de changer, mais lorsque ça arrivera, on aura un nouveau shp que je pourrais intégré directement dans postgis à la place de l'ancien, ça ne changera donc pas dans la table.
pour ce qui est de la concaténation, ça veut dire que sous postgres, je créé un nouveau champs avec la concaténation des deux champs de la clé multichamps ?
comment peut-on faire cela ?
merci beaucoup.
Dernière modification par nponzo (Wed 10 September 2008 12:20)
Hors ligne
#5 Wed 10 September 2008 12:54
- NyPon
- Participant actif
- Date d'inscription: 3 Nov 2008
- Messages: 111
Re: identifiant_geoconcept_postgres
Désolé pour la question de la concaténation,
j'ai réussit. je vais voir ce que ça donne sous géoconcept.
mais bon, on est quand même obligé de créer un champs dans géoconcept pour la selection des données lorsque l'on à des clés multichamps dont un champ n'est pas unique.
j'ai eu confirmation de la part de géoconcept, il vaut mieux mettre des champs autoincrémentés et ça fonctionne très bien, de plus ça respecte les canons des bases de données, car les clés multichamps présente le risque de ne pas être invariantes et d'être gérées par le système. c'est donc plus robuste lorsque des champs se répercutent dans de nombreuses tables.
merci de vos interventions.
à bientôt.
Dernière modification par nponzo (Thu 25 September 2008 12:23)
Hors ligne
