Discussion :

[martinbrait]

Je prolonge une discussion, évoquant l'importance du choix
des préfixes et suffixes de noms de table,
des préfixes et suffixes de noms de champ,
des mnémoniques de noms de champs
des désignations de noms de champs

Question fondamentale en matière d’écriture : sa nécessité

À propos de tes nouveaux noms de données…

Je tiens à mes préfixes (typologiques) devant chaque mnémonique de colonne.

J'y ajoute systématiquement la désignation en clair (dans la légende, sous access, ou en description, pour les autres SGBD).

Lors notamment de requêtes depuis des sources externes, je ne me pose pas 36 questions à enquêter sur la concordance de type entre la colonne source et la colonne cible.
Préfixer un nom de donnée d’une lettre représentant sa typologie pollue les développements :

en ajoutant inutilement deux caractères au nom de donnée,
en ajoutant une contrainte de gestion de tes développements,
en singularisant ta programmation non conventionnelle,
en contraignant une tierce personne à essayer de comprendre ta démarche alambiquée.


Des problèmes de concordance typologique entre une colonne source et une colonne cible se règlent au cas par cas, on est sensé savoir ce que l’on fait, quelles données on manipule.

Lorsque tu nommes tes données « kn_pers », « ak_matri », « kn_cm », je m’interroge à propos de ton « k » et ce n’est pas normal de devoir s’interroger.

À propos de tes noms de tables…

Lorsque tu nommes ta table « t_pers_prs », je m’interroge sur le préfixe « t_ » et le suffixe « _prs » qui semble être un alias de "pers". Si le préfixe « t_ » signifie « table », je ne vois pas l’intérêt. Quant-au suffixe « _prs », qu’apporte-t-il à part un questionnement pour une tierce personne ?

De même pour ta table « tr_grade_tgd2 » que tu cites dans ton autre discussion. Je présume que ton préfixe « tr_ » signifie « table référente ». Même remarque pour ton préfixe « _tr » et ton suffixe « _tgd2 ».

... Question fondamentale en matière d’écriture : sa nécessité.

Cela dit, je ne veux pas passer pour un donneur de leçons. Je fais part simplement de mes propres bonnes pratiques qui ont fait leurs preuves. Je les évoque car j’ai pu constater que le sujet n’est pas abordé dans les formations (IUT), comme s’il appartenait à chacun de se les inventer. J’ai pu le vérifier lors d’un DUT en formation permanente. On y enseigne la technicité, pas le savoir faire. J’ignore ton cursus formation mais il semble que ce soit toujours vrai.

Bonnes pratiques

Voici une liste de bonnes pratiques qui s’appliquent à la fois pour le nommage des tables et des colonnes:

Ne pas utiliser les mots réservés. Par exemple, il faut éviter de nommer une colonne “date” car ce mot est déjà utilisé
Documentation MySQL 5.6 : mots réservés
Documentation PostgreSQL 9.2 : mots clés SQL
Documentation SQL Server 2000 : mots réservés
Ne pas utiliser de caractères spéciaux


Noms de tables

Voici une liste de bonnes pratiques :

Utiliser un nom représentatif du contenu
Utiliser un seul mot lorsque c’est possible
Privilégier le singulier (mais c’est parfois un grand débat …)
Penser à des noms génériques et envisager les futurs évolutions. Par exemple une table “client” qui pourrait aussi contenir les prospects et commerciaux devrait plutôt s’intitulé “utilisateur”
Préfixer les noms des tables
Permet d’éviter d’utiliser accidentellement des mots réservés.
Permet d’éviter les conflits lorsqu’il y a plusieurs logiciels similaires sur une même base de données (par exemple, si 2 logiciels utilisent chacun une table intitulée “utilisateur”).
Utile pour séparer facilement les tables associée à un système ou à un autre. Par exemple si un blog WordPress et une boutique e-commerce Prestashop sont placé sur une même base de données, le blog aura des tables commençant par “wp_” tandis que la boutique aura des tables commançant par “ps_”.
C’est plus simple pour ré-installer un backup. Par exemple, pour réinstaller une sauvegarde du blog, il est possible d’ajouter des tables commençant par “wp2013_” puis de modifier le code de l’application pour tout migrer d’un coup.
Sur des gros projets ça peut être pratique pour que toutes les tables associées aux utilisateurs commence par exemple par “user_”, toutes celles concernant les produits par “product_” et ainsi de suite.

Noms de colonnes

Voici la liste de bonnes pratiques :

Préfixer toutes les colonnes de la même façon pour chaque table. C’est beaucoup plus pratique lorsqu’il convient d’effectuer des jointures.
Dans le cas d’un site à vocation multilingue : indiquer la langue et la zone géographie pour les champs alphanumériques (fr_fr pour le français de France, fr_ca pour le français du Canada, fr_be pour le français de Belgique …). C’est extrêmement pratique si un jour une application doit devenir multilingue. Si la base de données doit s’internationaliser il suffira d’ajouter une colonne supplémentaire avec les traductions.

Jean-Philippe AMBROSINO _ conventions typographiques du code.pdf

Frédéric BROUARD _ normalisation des noms des objets des bases de données.pdf

[CinePhil]

Ma norme de nommage...

1) POUR LES TABLES

a) Préfixes
tr_ : table de référence
te_ : table issue d'une entité type du MCD
th_ : table héritant d'une autre
tj_ : table de jointure (table associative mais dans le nommage de SQLPro, ta_ est pour les tables d'administration de la BDD, que je n'ai pas encore vraiment utilisées)

b) Suffixe
Code à 3 caractères, mnémotechnique.
Pour les tables associatives, le trigramme sera composé de l'initiale des trigrammes des tables entrant en jeu dans l'association, entourant celle du verbe de l'association.

c) La partie du nom expliquant le contenu de la table...
- Nom au singulier ;
- Si possible un seul nom mais pas toujours possible alors mots séparés par underscore ;
- Pour les tables associatives, reprise des trigrammes des tables entrant en jeu dans l'association et entourant le verbe à l'infinitif de l'association.

d) Exemples
tr_pays_pay => table de référence des pays
te_personne_prs => table issue de l'entité-type "personne" du MCD
th_personne_physique_pph => table d'héritage des personnes physiques (hérite de te_personne_prs)
tj_prs_visiter_pay_pvp => table associative issue de l'association "visiter" entre les entités-types "personne" et "pays"

2) POUR LES COLONNES

a) Préfixe
Celui de la table à laquelle appartient la colonne (toutes mes colonnes ont donc un nom différent par construction ; je ne réutilise pas le nom de la colonne de référence pour une colonne de clé étrangère).

b) Partie explicitant le contenu de la colonne
Toujours au singulier pour éviter les ambiguïtés d'interprétation.
Si possible, un seul mot, sinon, mots séparés par underscore.
Les identifiants sont toujours "id".
Les clés étrangères sont toujours id_[référence].

c) Exemples :
pay_id => identifiant du pays dans la table tr_pays_pay.
prs_nom_usuel => Nom usuel d'une personne dans la table te_personne_prs
pph_id_personne => Clé étrangère référençant la table des personnes dans la table des personnes physiques th_personne_physique_pph
pph_date_naissance = Date de naissance d'une personne physique


Je pourrais aussi parler du nommage des index et des clés étrangères et autres contraintes. En normalisant, on sait à quoi on a à faire et on peut capturer les erreurs SQL pour les interpréter, ou encore du nommage des vues, triggers, procédures...

Pratiquant ainsi depuis quelques années, je me suis rendu compte à quel point ça peut être pratique : je n'ai quasiment plus besoin de regarder mon schéma pour écrire mes requêtes ; ça devient quasi-automatique. Et rien qu'avec le préfixe d'une colonne, je sais de quelle table elle vient. De plus, je n'ai ainsi jamais de problème de nom de colonne ou table qui soit un mot du langage SQL ; par construction, c'est impossible.
Je n'ai encore jamais eu à les utiliser ainsi mais ce que dit SQLPro aussi dans sa norme c'est que c'est pratique pour interroger le catalogue (information_schema).

Bref, j'encourage fortement à se définir une norme de nommage et à utiliser le plus souvent possible les mêmes noms dans des projets différents ; ça augmente la productivité en développement.
Idem d'ailleurs côté code applicatif avec le nommage des classes, des variables, des vues...

[martinbrait]

Bref, j'encourage fortement à se définir une norme de nommage et à utiliser le plus souvent possible les mêmes noms dans des projets différents ; ça augmente la productivité en développement.
Idem d'ailleurs côté code applicatif avec le nommage des classes, des variables, des vues...

Concernant le trigramme de fin de table, je vote pour.
Pour l'instant, la présence du trigramme de table
me convient, en préfixe ou suffixe
de mes clés primaires autonum et clés étrangères numériques
afin d'identifier clairement leur dépendance.
Je suis encore en ballotage, côté avantage/inconvénient,
concernant l'utilisation systématique de ce préfixe à toutes les colonnes.
Pour mes colonnes d'attributs ordinaires,
exemptes de contraintes,mettre un préfixe allonge ma colonne, désavantage que je perçois.
Mettre un préfixe m'apporte t-il un bénéfice indiscutable, que je ne perçois pas encore ?.
Concernant mes noms de colonnes,même sans préfixe, je fais toujours attention à ce qu'ils soient uniques dans toute ma base.
Ma base est par ailleurs cloisonnée (sous Postgres) par des schémas distincts, qui m'aide à localiser mes noms de colonne.

Merci beaucoup pour cet échange !

[CinePhil]

Pour mes colonnes d'attributs ordinaires, exemptes de contraintes,j'ai l'impression qu'un préfixe les allonge systématiquement, sans m'apporter de bénéfice indiscutable.

1) Ça n'allonge pas beaucoup.
2) Même si ce ne sont pas des colonnes munies de contraintes (sous-entendu : clé étrangère ?), elles peuvent être présentes dans la partie SELECT ou WHERE, GROUP BY, HAVING, ORDER BY d'une requête, dans une vue ou une procédure SQL. Le trigramme permet d'identifier rapidement d'où vient la colonne quand on lit la requête, surtout si elle est longue.

Exemple de vue un peu complexe :

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
CREATE OR REPLACE VIEW v_candidature AS
SELECT 
	-- Candidat
	cd.cdt_id_candidat cdtIdCandidat,
	c.canPrenomUsuel cdtPrenomUsuel,
	c.canNomUsuel cdtNomUsuel,
	c.canIdSexe cdtIdSexe,
	-- Parcours
	cd.cdt_id_diplome_ensfea cdtIdDiplomeEnsfea,
    d.dpl_code cdtCodeDiplomeEnsfea,
	d.dpl_libelle_court cdtDiplomeEnsfea,
	cd.cdt_numero_mention cdtNumeroMention,
	m.men_code cdtCodeMention,
	m.men_libelle cdtLibelleMention,
	cd.cdt_id_specialisation cdtIdSpecialisation,
	s.spe_code cdtCodeSpecialisation,
	s.spe_libelle cdtLibelleSpecialisation,
	cd.cdt_id_option cdtIdOption,
	o.opt_code cdtCodeOption,
	o.opt_libelle cdtLibelleOption,
	-- te_candidature_cdt
	cd.cdt_id cdtId,
	cd.cdt_id_etat cdtIdEtat,
	e.eti_code cdtCodeEtat,
	e.eti_libelle cdtLibelleEtat,
	cd.cdt_id_session,
	se.ses_code cdtCodeSession,
	se.ses_libelle cdtLibelleSession,
	cd.cdt_date cdtDate,
	cd.cdt_annee_universitaire cdtAnneeUniv,
	cd.cdt_annee_dans_diplome cdtAnneeDansDiplome
FROM te_candidature_cdt cd
INNER JOIN v_candidat c ON c.canId = cd.cdt_id_candidat
INNER JOIN te_parcours_pcr p 
	ON p.pcr_id_diplome_ensfea = cd.cdt_id_diplome_ensfea
	AND p.pcr_numero_mention = cd.cdt_numero_mention
	AND p.pcr_id_specialisation = cd.cdt_id_specialisation
	AND p.pcr_id_option = cd.cdt_id_option
	INNER JOIN te_diplome_dpl d ON d.dpl_id = cd.cdt_id_diplome_ensfea
	INNER JOIN te_mention_men m 
		ON m.men_id_diplome_ensfea = p.pcr_id_diplome_ensfea
		AND m.men_numero = p.pcr_numero_mention
	INNER JOIN te_specialisation_spe s ON s.spe_id = p.pcr_id_specialisation
	INNER JOIN te_option_opt o ON o.opt_id = p.pcr_id_option
INNER JOIN tr_etat_inscription_eti e ON e.eti_id = cd.cdt_id_etat
INNER JOIN tr_session_ses se ON se.ses_id = cd.cdt_id_session

Imaginons que j'aie oublié de préfixer une colonne ou plusieurs de l'alias de la table et que j'aie écrit, par exemple, pour une colonne non préfixée par le trigramme de la table dont elle est issue, annee_universitaire, au lieu de cd.annee_universitaire.
Comme cette colonne n'existe qu'une seule fois, le SGBD sera capable de trouver la colonne et la vue pourra fonctionner.
Mais si je reviens un jour sur cette vue, comment je sais d'où vient cette colonne ? Je suis obligé d'aller chercher dans mon schéma... s'il a été tenu à jour, ou d'interroger le catalogue information_schema, ou de chercher dans la structure de chaque table utilisée dans la requête...
Au contraire, avec le préfixe cdt_, je sais immédiatement que la colonne vient de la table te_candidature_cdt ou bien, si je ne me souviens plus de ce trigramme, je le trouve dans la requête en tant que suffixe de la table. À l'usage, c'est vraiment très pratique. Et, encore une fois, ça évite le risque d'utiliser un mot réservé du SQL.