{"action":"created","issue":{"url":"https://api.github.com/repos/PnX-SI/TaxHub/issues/163","repository_url":"https://api.github.com/repos/PnX-SI/TaxHub","labels_url":"https://api.github.com/repos/PnX-SI/TaxHub/issues/163/labels{/name}","comments_url":"https://api.github.com/repos/PnX-SI/TaxHub/issues/163/comments","events_url":"https://api.github.com/repos/PnX-SI/TaxHub/issues/163/events","html_url":"https://github.com/PnX-SI/TaxHub/issues/163","id":358282888,"node_id":"MDU6SXNzdWUzNTgyODI4ODg=","number":163,"title":"Proposition d'évolution du MCD","user":{"login":"gildeluermoz","id":10024739,"node_id":"MDQ6VXNlcjEwMDI0NzM5","avatar_url":"https://avatars2.githubusercontent.com/u/10024739?v=4","gravatar_id":"","url":"https://api.github.com/users/gildeluermoz","html_url":"https://github.com/gildeluermoz","followers_url":"https://api.github.com/users/gildeluermoz/followers","following_url":"https://api.github.com/users/gildeluermoz/following{/other_user}","gists_url":"https://api.github.com/users/gildeluermoz/gists{/gist_id}","starred_url":"https://api.github.com/users/gildeluermoz/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/gildeluermoz/subscriptions","organizations_url":"https://api.github.com/users/gildeluermoz/orgs","repos_url":"https://api.github.com/users/gildeluermoz/repos","events_url":"https://api.github.com/users/gildeluermoz/events{/privacy}","received_events_url":"https://api.github.com/users/gildeluermoz/received_events","type":"User","site_admin":false},"labels":[{"id":195360065,"node_id":"MDU6TGFiZWwxOTUzNjAwNjU=","url":"https://api.github.com/repos/PnX-SI/TaxHub/labels/enhancement","name":"enhancement","color":"84b6eb","default":true}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":5,"created_at":"2018-09-08T10:18:06Z","updated_at":"2018-09-12T20:26:55Z","closed_at":null,"author_association":"CONTRIBUTOR","body":"Pour une éventuelle V2 ou V1.5\r\n\r\n**Constat**\r\n\r\nL'idée de structurer la taxonomie en 2 parties apparait indispensable :\r\n- le référentiel national taxref,\r\n- le référentiel de la structure. \r\n\r\nActuellement `bib_noms` n'est pas un référentiel. C'est ni plus ni moins qu'une liste extraite de `taxonomie.taxref`. Du coup on ne peut pas ajouter des taxons absents de taxref. Donc on n'a pas de référentiel de la structure mais on a la contrainte de gérer le contenu de `bib_noms` comme préalable à tout le reste.\r\n\r\nSur ces 2 référentiels, il y a un besoin d'enrichissement de ces référentiels avec les notions de listes et d'attributs permettant de répondre aux besoins locaux.\r\nSi on a deux référentiels dans 2 tables, on aura tjs un dilème : \r\n\r\n- lequel utiliser ? \r\n- quand ?\r\n- sur quelle table faire pointer les FK ?\r\n- et si on a besoin des deux on fait comment ? \r\n\r\nActuellement `bib_noms` est au centre des listes et des attributs alors qu'on se base toujours sur `cd_nom` ou `cd_ref`, présents dans `taxonomie.taxref`. En gros `bib_noms` n'apporte que le choix du nom_français et depuis peu la possibilité de commentaires. Il constitue par ailleurs une liste limitative des taxons de la structure.\r\n\r\nAutre soucis, les listes se basent uniquement sur les noms (cd_nom) et les attributs uniquement sur les taxons (cd_ref). Impossible de faire par exemple un attribut qui concernerait tous les synonymes d'un taxon ou de faire une liste avec uniquement des taxons de référence.\r\n\r\n**Propositions**\r\n\r\n- supprimer `bib_noms` et donc du coup le `id_nom` tout pourri et totalement inutile car chaque `cd_nom` unique a un `id_nom` unique...\r\n- ajouter un champ `inpn` (true/false) à `taxonomie.taxref`,\r\n- ajouter les qq taxons du référentiel de la structure à la table `taxonomie.taxref` avec `inpn = false`,\r\n- ajouter un champ `is_ref` a `bib_attributs` et `bib_listes`,\r\n- faire pointer `cor_nom_liste` et ` cor_taxon_attribut` sur le `cd_nom` de taxref au lieu de pointer sur `bib_noms` et utiliser le champ `is_ref` de `bib_listes` ou `bib_attributs` dans une contrainte pour savoir si l'attribut ou la liste doit accueillir uniquement des taxons de référence ou si elle peut accueillir des synonymes. `CONSTRAINT CHECK (f_is_cd_nom_matching_with_attribut(cd_nom, id_attribut)`. \r\nAvec la petite fonction qui va bien :\r\n```\r\nCREATE OR REPLACE FUNCTION f_is_cd_nom_matching_with_attribut(cd_nom integer, id_attribut integer)\r\nRETURNS BOOLEAN AS \r\n$$ \r\nDECLARE\r\n  attr_is_ref boolean;\r\nBEGIN\r\n  SELECT INTO attr_is_ref is_ref FROM taxonomie.bib_attributs WHERE id_attribut = $2;\r\n  IF ((attr_is_ref AND $1 == taxonomie.find_cdref($1)) OR !attr_is_ref) THEN \r\n   RETURN true;\r\n  ELSE \r\n    RETURN false;\r\n  END IF;\r\nEND;\r\n$$ \r\nLANGUAGE plpgsql IMMUTABLE \r\nCOST 100;\r\n```\r\n- ajouter une liste \"taxons_structure\",\r\n- gérer le nom_français à retenir dans un attribut `nom_fr`,\r\n- gérer les commentaires dans un attribut `commentaire`.\r\n\r\nAinsi :\r\n* on garde toute la richesse de la hiérarchie taxonomique pour nos deux référentiels,\r\n* on peut facilement isoler les taxons du référentiel structure avec le champ `inpn` (migration taxref, export, transmission à l'INPN pour expertise, etc...), \r\n* squand elles existent, on peut établir des correspondances entre le référentiel de la structure et le référentiel INPN avec les champ `cd_ref` et `cd_taxsup`,\r\n* TOUTES les références vers cd_nom ou cd_ref (FK ou jointures) se font sur une seule table,\r\n* on donne la possibilité aux listes de référencer des taxons et plus seulement des noms, sans avoir à créer  `cor_taxon_liste` à coté de  `cor_nom_liste`,\r\n* idem, on donne la possibilité aux attributs de référencer noms ou taxons sans avoir à créer `cor_nom_attribut` à coté de `cor_taxon_attribut`,\r\n* on peut limiter les requêtes aux taxons de la structure avec la liste \"taxons_structure\",\r\n* on répond peut-être, au moins partiellement à ce besoin : https://github.com/PnX-SI/TaxHub/issues/159."},"comment":{"url":"https://api.github.com/repos/PnX-SI/TaxHub/issues/comments/420785647","html_url":"https://github.com/PnX-SI/TaxHub/issues/163#issuecomment-420785647","issue_url":"https://api.github.com/repos/PnX-SI/TaxHub/issues/163","id":420785647,"node_id":"MDEyOklzc3VlQ29tbWVudDQyMDc4NTY0Nw==","user":{"login":"camillemonchicourt","id":4418840,"node_id":"MDQ6VXNlcjQ0MTg4NDA=","avatar_url":"https://avatars0.githubusercontent.com/u/4418840?v=4","gravatar_id":"","url":"https://api.github.com/users/camillemonchicourt","html_url":"https://github.com/camillemonchicourt","followers_url":"https://api.github.com/users/camillemonchicourt/followers","following_url":"https://api.github.com/users/camillemonchicourt/following{/other_user}","gists_url":"https://api.github.com/users/camillemonchicourt/gists{/gist_id}","starred_url":"https://api.github.com/users/camillemonchicourt/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/camillemonchicourt/subscriptions","organizations_url":"https://api.github.com/users/camillemonchicourt/orgs","repos_url":"https://api.github.com/users/camillemonchicourt/repos","events_url":"https://api.github.com/users/camillemonchicourt/events{/privacy}","received_events_url":"https://api.github.com/users/camillemonchicourt/received_events","type":"User","site_admin":false},"created_at":"2018-09-12T20:26:55Z","updated_at":"2018-09-12T20:26:55Z","author_association":"MEMBER","body":"C'est clair que les listes c'est quand même plus parlant, plus lisible car tu vois ce qui est dedans ou pas, tu peux les lier à des groupes et c'est plus facile à remplir que des attributs nom par nom. \r\n\r\nD'ailleurs j'ai renommé l'attribut \"Saisie possible\" en \"Saisie Occtax\" dans cette idée qu'il y a une liste par module. \r\n\r\nMais à creuser en effet les pistes que tu évoques pour ajouter de nouvelles possibilités. "}}
{"actor":{"display_login":"camillemonchicourt"}}