Il m'est arrivé, pour le compte de mon client préféré, de devoir rédiger une documentation sur les conventions de nommage des scripts et objets de BD.
Après maintes recherche sur le web....rien du tout ou presque ! Enfin...que des directives différentes, voire contradictoires.
J'ai donc repris mes bouquins MS que j'utilisais pour passer mes certifs et le point est effectivement abordé, résumée par la phrase suivante :
ce qui importe, ce n'est pas la convention de nommage utilisée, c'est que votre système d'information dispose d'une convention de nommage et l'applique.
Fort de ce principe, je me suis donc attelé à la tâche. Certains principes que j'ai pu retrouver dans différents SI ont été repris. En voici une shortlist :
- Utilisation de préfixes pour différencier les objets de bases de données
- Références de mêmes noms
- Suffixe pour les champs identifiants
- ...
Voici donc un exemple assez restreint mais qui aborde l'essentiel d'une nomenclature sous SQL Server :
- les bases : aucune préconisation particulière mise à part éviter les symboles non alphanumériques, souvent en majuscules...
- les tables : T_Personnes
- le modèle relationnel impose des noms d'entités au singulier mais bien souvent, pour raisons historiques, on conserve des noms au pluriel pour les tables
- Les vues : V_PersonnesActives
- les champs : PersonneId
- pour le champ identifiant
- Prenom
- une majuscule puis minuscule pour les champs standards
- les champs qui sont clés étrangères : PersonneId
- même nom que les clés primaires référencées
- Les clés :
- PK_Personne ou PKC_Personne si l'index est clustered pour une clé primaire
- FK_Personne_Addresse pour une clé étrangère (les noms des deux tables sont indiqués).
- Les indexs :
- IXF_Personne_Prenom pour un index non unique et non clustered
- IXU_Personne_Surnom pour un index unique non clustered
- Les triggers : TR_Personne_CheckPersonne
- Les contraintes :
- CK_Identity_CheckControle : contrainte de type CHECK, porte sur le type de vérification
- DF_DateCreation : contrainte de type DEFAULT
- U_Surnom ou UC_Surnom voire UK_Surnom mais je suis moins fan, pour les contraintes UNIQUE.
- Les fonctions : F_PERSONNE_AjouteAmi,
- le nom de la table peut être remplacé par le nom du domaine fonctionnel dans lequel s'exerce la fonction (ex : F_USERSECTION_AjouteAmi)
- Les procédures stockées : idem fonctions : P_PERSONNE_AjouteAmis
Quoi qu'il en soit, le principal objectif d'une bonne nomenclature est de bien différencier les nombreux objets de BD utilisés, pour pouvoir identifier rapidement l'un d'entre eux, car très vite, on peut se retrouver noyer dans un flot de code SQL...
