BDD - Convention de nommage

[lpofredc]

En lien avec le ticket #880 et la PR #984, il serait intéressant d'intégrer à la doc un minimum d'éléments sur les conventions de nommage utilisés dans GeoNature, sur les différentes briques du projet:

Par exemple côté bdd par exemple:

• index préfixés par i_
• fonctions par fct_
• fonctions de trigger par fct_tri
• triggers par tri_
• tables de données par t_
• tables de dictionnaires par bib_
• tables de correspondances par cor_table1_table2
• etc.

Personnellement, de notre côté, nous avons pris le toujours nommer les objets au singulier. en lien avec la pr #984, nous aurions donc nommé la table t_place. C'est un parti pris.

Nous pouvons nous charger de cette ajout de doc pour le bloc bdd.

[gildeluermoz]

Très bonne idée. Voici ce qu'on a fait depuis le début du projet en complément :

• les objets sont au pluriel : t_parameters
• les clés primaire et les autres champs portant le nom de la table au singulier : id_parameter, parameter_name, etc...
• les tables de correspondance porte le nom de leurs tables référencées au singulier avec le préfixe "cor": cor_param_nomenclature
• les PK et les FK correspondantes portent généralement le même nom
• mêmes si on n'a pas toujours été rigoureux, on essaie de respecter une forme de nommage pour les noms des FK et des PK comme :
  • pk_t_parameters
  • fk_cor_dataset_actor_id_dataset

[DonovanMaillard]

Pour les nouvelles tables type bibliothèque, avec camille nous avions discute de basculer sur dict pour "angliciser " la base, pour dictionnaire/dictionnary A voir sil faut ou non faire cette modof mais camille m'avait demandé de tout passer de bib à dict pour le module d'import.

[camillemonchicourt]

Il y a quelques éléments sur la sujet dans la doc, mais certainement à compléter : http://docs.geonature.fr/admin-manual.html#base-de-donnees

Les tables des objets sont au pluriel. Donc c'est bien t_places pour être cohérent avec l'existant. Et il y a toujours quelques petits ratés ou oublis, ou restes d'historiques.

Par exemple les schema taxonomie de TaxHub et utilisateurs de UsersHub sont encore en français. Les migrer serait bien mais pas anodin donc mis de côté pour le moment. Voir https://github.com/PnX-SI/GeoNature/issues/225

[lpofredc]

Ok, merci. Ou placer cette doc? Dans Manuel administrateur ou Developpement? Les deux se défendent.

• Dans Manuel administrateur pour aider le db admin à s'y retrouver
• Dans Developpement pour cadrer les développements/évolutions à venir.

[camillemonchicourt]

Oui en effet. Pour le moment c'est dans l'intro de la partie BDD du manuel Administrateur : http://docs.geonature.fr/admin-manual.html#base-de-donnees

Du coup je continuerai à cet endroit.

Merci.

[lpofredc]

Je rebondis sur l'anglicisation des nommages, je suis d'accord sur cette approche. Il serait intéressant de se caler là dessus.

• tables de données t_ > reste t_
• dictionnaires bib_ > dict_?
• correspondances cor_ > cor_ ou match_?
• vues matérialisées vm_ > mv_ ?
• ...

Aussi, nous proposons une codification permettant d'identifier les objets personnels propres à chaque instances (tables et vues ajoutées notamment). Pour cela, nous envisageons l'ajout d'un second préfixe c_ pour custom. Par exemple, nous avons une table de correspondance des taxons VisioNature avec Taxref, elle se nommerait donc taxonomie.cor_c_vn_taxref et sa vue taxonomie.v_c_cor_vn_taxref pour identifier une table de correspondance "non native" de GeoNature. Chacun peut bien sûr le faire à sa sauce mais cela permettrait de disposer d'une base commune.

[camillemonchicourt]

Si on décide (un jour) de reprendre ça pour tout passer en anglais, voici un petit retour concernant dict_ :

dict_ fait beaucoup trop référence à un dictionnaire en programmation, i.e. une association clef / valeur, pas à un référentiel. En alternative, peut-être list_ ou enum_. enum ça fait bien penser à une liste de valeurs en programmation.

De mon côté, list_ me semble le plus clair et explicite.

[DonovanMaillard]

j'avoue que dans la pratique, tout l'outil est construit autour des champs standards francais, des nomenclatures francaises, d'un référentiel taxonomique francais, avec un interfacage francais, des dépots largement discutés en francais au niveau des issues et meme des commentaires dans le code. Avoir un préfixe bib_ me semble pas pariculièrement problématique tant qu'on a pas migré sur darwin core avec des docs et des interfaces multilingues ;) ce qui devrait nous laisser 2-3 mois de marge.. au moins.