Règles et conventions de nommage SQL
Par PlaceOweb le samedi, avril 24 2010, 11:45 - SQL - Lien permanent
Quelle norme de nommage SQL (MySQL, Oracle, Postgres, MsSQL, ...) choisir pour le nom :
- des bases de données,
- des tables,
- des colonnes.
Règles de standardisation SQL et conventions de nommage des objets SQL
Normalisation des noms des objets des bases de données
Pattern : "[a .. z] + [A .. Z] + [0 .. 9] +[ _ ]" avec les restrictions suivantes :
- ne pas dépasser 128 caractères
- ne doit pas commencer par un chiffre
- ne peut avoir plusieurs caractères "blanc souligné" de suite
- la casse n'a pas d'importance
- le nom ne doit pas être un mot réservé de SQL
Règles de nommage
Un nom d'objet (table, colonne, contrainte, vue...) doit avoir les caractéristiques suivantes :
- ne pas dépasser 128 caractères
- commencer par une lettre
- comprendre uniquement les caractères suivants [ 'A' .. 'Z'] U ['a' .. 'z'] U [ '0' .. '1'] U [ '_' ]
- un nom d'objet ne peut pas être un mot réservé de SQL sauf à être utilisé avec des guillemets
- être insensible à la casse
Convention de nommage
Les avis divergent :
- Nom des tables :
- toujours en minuscule
- toujours au singulier
- toujours au masculin
- jamais d'accents
- si c'est une table de jointure (exemple les articles de la commande) table dans l'ordre alphabétique : article_commande
- jamais d'abréviations
- Nom des colonnes :
- clef primaire : id_ + nom de la table
- libellé : lib_ + nom de la table
- date de création de l'enregistrement : cre_ + nom de la table
- date de modification : mod_ + nom de la table
- description : des_ + nom de la table
- Nom des index : ndx_ + nom table + nom_des_colonnes (abrégé seulement si > 64 caractères)
Table.abreviationTable_champs ou Table.champs ?
table PERSONNE (pers_id,pers_nom,pers_prenom,...)
ou
table PERSONNE (id,nom,prenom,...)
Alexandre T utilise "Table.abreviationTable_champs" pour
- la modélisation des données
- pour éviter les confusions lors de la réalisation de requêtes
- pour les outils de reporting qui assiste l'utilise et proposent eux même les jointures
Mais Mogwaï s'y oppose :
On a des tables d'association qui lient jusqu'à 5 tables. On se retrouve avec des nom de table à rallonge qui ne veulent finalement rien dire et qui pourraient se résumer en un seul mot. Et on a par dessus le marché des noms de champs interminables : jusqu'à 60 caractères.
Règles de nommage des champs
Il n'y a pas de règles mais peut être quelques usages essentiellement dictés par :
- la lisibilité des éventuelles requêtes SQL qu'on va faire sur la base... Et le fait que nous allons utiliser des identifiants construits avec des mots "composés". Pour discerner ces mots: CamelCase: ClientId ou séparation par '_': client_id
- Nom composés. nomClient ou ClientNom; idClient ou ClientID: utiliser le nom de l'entité en préfixe plutôt que celui de l'attribut. C'est cohérent avec la régularité de la hiérarchie précédente. Utiliser '_' comme séparateur me convient mieux visuellement mais il y a des règles simples pour naviguer entre ClientNom et client_nom
- Foreign Key : FK_idClient pourquoi de pas se contenter de 'Client', i.e Commande.Client relie la commande au Client. Si vous voulez être plus précis, Commande.ClientIdent ou Commande.ClientID disent la même chose mais avec une contrainte différente sur la réalisation.
Définition des données
Choisir des règles de nommage pour les tables et les colonnes. Par exemple, il peut y avoir le choix d'utiliser des noms au pluriel ou au singulier pour les noms de table, chaque choix ayant les faveurs d'un théoricien ou d'un autre.
SQL : PDO fetch : MySQL & Oracle & SQL : Oracle MySQL SQL Server Compact Edition, les différences entre les moteurs SQL
// MySQL $row['maColonne'] // Oracle $row['MACOLONNE']
http://lutece.paris.fr/fr/tech/naming-conventions.html
Objets de base de données
Tous les noms de table et de colonne doivent être en minuscules en séparant les mots par des underscores.
Les requêtes SQL
Les requêtes SQL des classes DAO (couche métier) doivent être placées dans des variables de type string et doivent respecter la forme suivante:
* mots clés en majuscules (SELECT, UPDATE, WHERE , AND …), * noms des colonnes en minuscules, * alias des noms de colonnes sous forme de lettres de l’alphabet
Exemple de syntaxe:
String strSQL = "SELECT a.id_theme, a.description_theme \
FROM theme a, theme_newsletter b WHERE \ a.id_theme = b.id_theme and b.id_newsletter = ? ";
Microsoft SQL Server : Les Colonnes d'une Table
Si le nom est une combinaison de mots, chaque mot commencera par des majuscules. Exemples Date Hired, LastName, Drivers License Number, ou EmailAddress
Choix personnel
Puisqu'il n'existe aucune convention de nommage SQL standard, il faut bien faire des choix différents critères :
- problème de modélisation
- problème d'accession aux index des rows retournés selon les SGBD : "tableColonne1" "TABLECOLONNE1" "tablecolonne1"
- problème de longueur de nom de colonne, quand par exemple on les préfixe avec le nom de la table : "table_colonne1"
- ORM compatible ?
Table au pluriel ou au singulier ?
Table nommée au singulier : dans des cas spécifiques, vous nommez vos tables avec des noms métiers "goldorak" et le les mettre au pluriel le conviendrait pas puisque qu'un nom propre est invariable.
Table.abreviationTable_champ ou Table.champ ?
"table.champ" est suffisent pour identifier l'attribut concerné de la table.
ID (auto-incrément) : Table.id ? ou Table.table_id, voir Table.id_table ?... && éviter d'avoir des noms de colonnes identiques lors d'une requête multi-tables
bonne question... car si toutes les tables on un champ "id", lors d'un SELECT *, on risque d'avoir de multiples choix à spécifier lors du get().
MAJUSCULE, minuscule, camelCase ou avec_des_underscore ?
Selon la SGBD, les retours de nom de colonne lors du parcours du tuple (row ou enregistrement) diffèrent, et par exemple en PHP en fetch(ASSOC) :
- MySQL : camel_case
- Oracle : upper_case
- Postgres : lower_case
Donc si l'on doit être compatible pour plusieurs SGBD, il est plus simple de forcer le connecteur à retourner de la casse en majuscule ou en minuscule, mais surtout pas d'écriture de chameaux : camelCase. J'opterai pour le tiret bas "_"(underscore)
Les jointures ?...
- table1.id
- table1.nom
- table2.id (identique à table1.id)
- table2.prenom
Faut-il nommer "table2.id" en :
- table2.id
- table2.table1_id
- table2.id_table1