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é
  • 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:

Base de données merise d'un forum

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.

Ce contenu a été publié dans Bonnes pratiques.

A propos de l'auteur : Tony Archambeau

Fort de plusieurs années d’expérience dans le développement web, Tony partage ses connaissances sur des projets divers dont le site infowebmaster.fr.
Il est possible de le suivre sur Twitter.

Partager

9 réflexions au sujet de « Bonnes pratiques pour le nommage des tables et colonnes »

  1. vic dit :

    Merci pour cette liste de bonnes pratiques mysql ! Un bon récap :)

  2. alex dit :

    Toujours bien réviser les bonnes pratiques, merci ;)

  3. Hans dit :

    Je comprends ton avis sur les préfixe des noms de tables/colonnes, mais moi je préfère garder des noms métiers.
    Dans ton exemple (celui de gauche), la requête s’écrit simplement:
    SELECT p.`id`, p.`contenu`, t.`id` AS topic_id, p.`nom`
    FROM `post` p
    INNER JOIN `topic` t ON t.`topic_id` = p.`id`

  4. Nikolian dit :

    Préfixer les noms de colonnes rallonge nettement les requêtes n’impliquant qu’une seule table

    Select fourn_nom, fourn_prenom, fourn_adresse, fourn_codepostal, fourn_ville from fournisseurs

    Pas franchement utile et cela ne facile en rien les jointures

    Select f.nom,f.prenom, c.idcommande from fournisseurs as f inner join commandes as c on c.idfournisseur=f.idfournisseur

  5. Robinson dit :

    Salut Tony,
    Avec qu’elle logiciel fais tu tes schémas?

  6. Sébastien dit :

    Et éviter le franglais ?

    Voir des columns « nom » et « added_datetime » …
    Pourquoi ajouter le type de la column ?

    Pour moi dans les exemples, ça serait plutôt :
    « nom » -> « name »
    « contenu » -> « content »
    « last_modif_datetime » -> « last_update »

  7. shadow dit :

    C’est bien de rappeler les bonnes pratiques lors de la conception d’une base de donnée sans oublier le contexte multi-langue au cas ou.
    Concernant le nommage des tables je préfixe par {ref_} les tables ne servant que comme référentiel tel que les pays, les villes, une liste de catégorie ou bien de domaine de travail par exemple.
    Cela permet de savoir clairement quelles sont les répercutions et le rôle de ces tables dans une base de donnée conséquente.

  8. Mr monsieur dit :

    Salut,
    J’aime ce site, c’est bien de partager les bonnes pratiques, sinon comment pourrait on reprocher aux dba leurs choix merdiques.

    Bref, travaillant beaucoup dans les bases de données, je trouve que c’est une excellente initiative, et je pense aussi que beaucoup devraient lire ces lignes. Surtout les concepteurs de progiciels, putain !

  9. Mr monsieur dit :

    Surtout que c’est au moment de concevoir la base qu’on doit prendre en compte l’intégralité de ces « bonnes pratiques » : au tout début, avant TOUT.
    Trouver un endroit ou tout est centralisé, ça rassure.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *