La mise en place d'une convention de nommage améliore grandement la lisibilité du code SQL.

Table des matières

Convention simple de nommage des objets

				
					--Requête d'exemple qui n'a aucun sens (pas de polémique sur l'*)
Select top 10 * from dbo.Clients as cl
inner join dbo.Commands as cm on cm.ClientId = cl.ClientId

La requête n’est pas fausse au demeurant, mais quels types d’objets référence-t-elle?

Une table ? une vue ? les deux ?
Ce code n’est clairement pas lisible, si je dois aller voir la définition de l’un des objets, je vais probablement aller chercher en premier dans les tables, puis si je ne trouve rien, dans les vues.
C’est une perte de temps inutile…

C’est pour cette raison qu’une convention de nommage clairement définie est toujours préférable.
Après, le fait d’utiliser des minuscules, des majuscules ou les deux est un choix à discuter.
*Les setup SQL en mode Case Sensitive sont rares mais ils existent.

Identification simple des types d'objets

Voici les préfixes que j’applique personnellement de manière générale pour identifier les objets.

1- [t_ ou T_] pour les tables (Ex: t_Clients).
2-[v_ ou V_] pour les vues (Ex: v_Clients).
3-[up_ ou UP_] pour les procédures (User Procedure) (Ex: up_MaProc) sp_ et xp_ sont des préfixes réservés.
4-[if_ ou IF_] pour les fonctions INLINE (Ex: if_MyInlineFunction)
5-[tf_ ou TF_] pour les fonctions de type table (Ex: tf_MyTableFunction).
6-[sf_ ou SF_] pour les fonctions scalaires (Ex: sf_MyScalarFunction).
7-[udt_ ou UDT_] pour les types définis par l’utilisateur (User Define Type) (Ex: udt_MyDefineType)
8-[udtt_ ou UDTT_] pour les types table définis par l’utilisateur (User Define Table Type) (Ex: udtt_MyTableType)
9-[syn_ ou SYN_] pour les synonymes (Ex: syn_MySynonym).
10-[pf_ ou PF_] pour les fonctions de partition (Ex: pf_MyPartitionFunction).
11-[ps_ ou PS_] pour les schémas de partition (Ex: ps_MyPartitionScheme).

Organisation des objets par schéma

Sur SQL Server, les schémas sont avant tout faits pour gérer la sécurité à un niveau supérieur.
Il est plus facile d’appliquer des droits au niveau schéma plutôt que de le faire au niveau de chaque objet.

Mais les schémas peuvent aussi être utilisés comme NameSpace (espace de nom) sans pour autant porter préjudice à leur rôle initial.

				
					--Requêtes d'exemple qui n'ont aucun sens (pas de polémique sur l'*)
--Objet non identifiable
Select top 10 * from dbo.MyObjectName 
--Référentiel supposé
Select top 10 * from dbo.rf_MyObjectName 
--Référentiel supposé
Select top 10 * from dbo.ref_MyObjectName 
--Référentiel supposé avec convention de nommage (t_)
Select top 10 * from dbo.t_ref_MyObjectName

Tous les cas exposés ci-dessus ne sont pas vraiment efficients.
C’est là que les schémas entrent en jeu.
Voyons la différence ci dessous :

				
					--Requêtes d'exemple qui n'ont aucun sens (pas de polémique sur l'*)
--Table de référence
Select top 10 * from ref.t_MyObjectName 
--Table de liens
Select top 10 * from link.t_MyObjectName 
--Dictionnaire
Select top 10 * from dic.t_MyObjectName 
--Table de faits
Select top 10 * from fact.t_MyObjectName

L’utilisation des schémas comme NameSpace rend le code SQL encore plus lisible.
Voici les différents schémas qu’il m’arrive d’utiliser en fonction des besoins et du type de base de données.

1- [ref ou REF] pour les référentiels.
2- [dic ou DIC] pour les dictionnaires.
3- [link ou LINK] pour les tables de liens.
4- [fact ou FACT] pour les tables de faits.
5- [stg ou STG] pour les tables de Staging.
6- [clr ou CLR] pour les éventuels fonctions CLR, je préfère les identifier clairement.
Etc…

Pour conclure sur ce sujet, il est relativement facile de mettre en place une convention de nommage qui permette d’identifier facilement les objets en fonction de leur type, de leur rôle et de leur appartenance à un schéma.