Bonnes pratiques pour le nommage des tables et colonnes

Lors de la création d’une base de données il convient d’utiliser de bonnes pratiques pour faciliter la lecture, prévenir les bugs et éviter des erreurs lors du développement. Cet article présente quelques bonnes pratiques lors de la conception d’un schéma de données. Ces bonnes pratiques se basent à la fois sur des conventions recommandées par le plus grand nombre et sur une expérience personnelle.

A noter : ces recommandations n’ont pas pour vocation à être adoptée unanimement, il convient à chacun de définir ses propres conventions du moment de s’y tenir.

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
• Eviter les majuscules. Pour écrire 2 mots il faut privilégier l’utilisation d’un underscore. Par exemple il faut plutôt utiliser “date_inscription” que “DateInscription”
• Eviter l’utilisation d’abréviation. A première vu c’est pratique pour faire noms de tables pas très long, mais dans la pratique un développeur ne comprendra pas facilement à quoi ça correspond et il devrait visualiser le contenu pour comprendre ce qui se cache derrière

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.
• Lorsqu’une clé étrangère est utilisée (traduction anglaise : “Foreign Key”), il est pratique de l’indiquer dans le nom de la colonne. La colonne peut contenir le préfixe, puis “fk” pour Foreign Key, puis le nom de la table et enfin se terminer par “id”. Ainsi, une colonne pourrait s’intituler “wp_fk_user_id” (cf. préfixe “wp”, foreign key sur la table utilisateur de la colonne “id”).
• Toujours intitulé de façon similaire certains champs tels que les DATE ou DATETIME. Cela permet d’aider un développeur à savoir ce que va contenir un champ sans nécessairement regarder le contenu.

Exemple

Imaginons les tables d’un forum. Il peut y avoir 3 tables : une pour les forums, une autre pour les questions et une dernière pour les messages. Ces tables sont liées entres elles grâce à des clé étrangères.

Schéma

Ci-dessous il est présenté 2 façon distinctes de nommer les tables d’une telle application:

L’exemple que je recommande est l’exemple de droite. Cet exemple utilise des préfixe et respecte une bonne convention de nommage pour savoir ce que peux contenir les colonnes.

Requêtes

Voici l’exemple d’une requête avec le mauvais nommage :

SELECT `post`.`id` AS post_id, `post`.`contenu` AS post_contenu, `topic`.`id` AS topic_id, `topic`.`nom` AS topic_nom
FROM `post`
INNER JOIN `topic` ON `topic`.`topic_id` = `post`.`id`

Cette requête est un peu longue et compliquée. Il faut par exemple utiliser le nom de la table pour éviter des erreurs où SQL ne sais pas différencier quel colonne est appelée. C’est indispensable pour éviter l’erreur : “nom de colonne ambigu”.

Cette requête SQL peut être simplifiée en utilisant des règles de nommages:

SELECT `p_id`, `p_description_fr_fr`, `t_id`, `t_nom_fr_fr`
FROM `f_post`
INNER JOIN `f_topic` ON `t_id` = `p_fk_topic_id`

Quoi d’autre ?

Si vous utilisez d’autres règles de nommages, n’hésitez pas à les partager dans les commentaires. Si vous utilisez des règles en contradictions avec celles-ci n’hésitez pas à les partager également.