Introduction

Dans cet article, nous allons voir comment bien nommer les tables et les champs.

Cela peut sembler inutile, c’est pourtant un des aspects fondamental d’un système informatique.

Ce n’est pas pour rien que les grosses entreprises tech donnent des lignes de conduite extrêmement précises à leurs développeurs pour ce qui est du format du code, de la nomenclature des variables, etc.

Pour vous donner un exemple concret, Airbnb a prévu un Github de l’équivalent de 80 pages contenant les bonnes pratiques à suivre lorsqu’on développe en Javascript pour eux.

Les bonnes pratiques de nommage dans Airtable

Ce n’est pas parce qu’Airtable est un outil « no-code » que ces bonnes pratiques ne s’appliquent pas !

Certe, elles sont moins présentes car le fonctionnement est plus explicite et plus guidé mais il reste important de bien nommer ses tables et ses champs.

Règles générales

• on utilisera la même langue partout (français ou anglais, pas un mélange des deux)
• on respectera le « domaine » et on ne re-définira pas celui-ci constamment
  • Ma base de données représente la gestion de mon entreprise
    • Ma table Clients représente donc les clients de mon entreprise
      • Pas besoin de préciser « Les clients DE MON ENTREPRISE »
    • Même chose pour les champs contenus dans la table Contacts
      • Pas de besoin de préciser Email DU CONTACT car on est dans la table contact, c’est donc implicite.

Nommage des tables

Les règles de base pour bien nommer ses tables

• le nom doit représenter ce que contient la table
• le nom doit TOUJOURS être au pluriel (car la table contient PLUSIEURS lignes)
• le nom doit être dans la même langue que le reste de la base

En pratique, on évitera donc :

• Mes clients
• Clients de ma société
• Client

On privilégiera donc simplement :

• Clients

Nommage des champs

Les règles de base pour bien nommer ses champs

• le pluriel a un sens
  • si on lie une commande à un client, on nommera le champ Client et pas Clients.
  • un mauvais nommage ici peut générer des erreurs d’interpretation
• un champ booléen (vrai/faux) se nomme différemment
  • exemple, on souhaite stocker le fait qu’un client soit « Actif » ou non.
  • on va créer un champ Est actif ? et pas simplement Actif.
  • c’est une astuce tout simple qui vous permettra rapidement de savoir le type de donnée stocké dans ce champ.
  • Autre exemple : un champ formule qui dit si la personne est majeure s’appellera Est majeur(e) ?
• on évitera de répéter le nom de la table dans le champ
  • si on est dans une table Contacts
    • On appelera simplement notre champ Prénom et pas Prénom du contact
    • En effet, c’est évident qu’il s’agit du prénom du contact car nous sommes dans la table dédiée aux contacts

Conclusion

Ceci sont mes guidelines et n’engagent que moi.

Comme toutes guidelines, elles peuvent être discutées, revues, corrigées, améliorées. (et je serais ravi d’en discuter avec vous en commentaire).

Néanmoins, elles peuvent servir de « base » pour votre réflexion et pour vous guider dans le nommage des tables et des champs.