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

• Oracle
  • Oracle column name case
  • Thread: Oracle Table and Column name Bug

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