Bien nommer ses champs

Considérations générales

MÉTHODOLOGIE	DESCRIPTION	BONNE PRATIQUE	MAUVAISE PRATIQUE
Utiliser le singulier	Nous considérons que les champs sont à noter au singulier (même pour un champ de type “Multiple choices”)	country_name email company_phone content current_month	countries_name email_adresses
Utiliser l’anglais	Toutes les tables sont nommées en anglais pour faciliter la compréhension par les équipes internationales, pour éviter les problématiques des accents et pour faciliter la maintenabilité.	country_name email	nom_pays courrier_electronique
Utiliser les minuscules	Pour faciliter l’écriture, les noms des tables ne contiendront pas de majuscule.	country_name email	COUNTRY_NAME Country_Name
Utiliser un underscore _ plutôt d’un espace ou un tiret	Cette écriture se rapproche de ce qui se fait le plus dans l’écosystème des bases de données. Nous avons choisi de conserver cette pratique.	country_name current_month	country-name_european-union e-mail
Utiliser un terme descriptif et court	En 1 ou quelques mots, la table doit pouvoir indiquer son contenu et son objectif. Plus le nom est court, mieux c’est. Eviter également les “stop word” (of, a…)	country_name current_month	Faites de votre mieux pour améliorer la lisibilité et la maintenabilité.
❌  Ne pas utiliser d’abréviation	Cela ne facilite pas la lecture et la compréhension de la table d’abréger des termes.	direct_message current_collab	current_collab dm
❌ Ne pas utiliser d’accent, d’emoji, de ponctuation ou de guillemet	Éviter absolument ces caractères car ils pourraient poser des problèmes techniques lors des requêtes à la base de données.		important_message! 🚨 important_message message_envoyé'
Faire en sorte que le champ soit le plus unique possible sur toute la base de données pour éviter les confusions

NOTE

chaque table doit absolument posséder a minima un champ id (identifiant unique) ainsi qu’un champ date de création. Le champ date de création sera nommé created_on et correspond comme son nom l'indique, à la date de création du record.

Considérations particulières

Champ id

Le champ id (identifiant unique) est le champ qui identifie chaque record de votre table.

WARNING

Attention : Sur un grand nombre d’outils no code l’id que vous choisissez n’est pas nécessairement la véritable primary_key.
Exemple : sur Airtable, la véritable clé primaire est celle du RECORD_ID(). Vous pouvez l’utiliser comme identifiant et dans ce cas utiliser le terme de primary_key (ou pk si vous le souhaitez), mais si vous préférez avoir un identifiant plus personnalisé pour une meilleure lecture (exemple : email), il est préférable de nommer le champ id.

MÉTHODOLOGIE	DESCRIPTION	BONNE PRATIQUE	MAUVAISE PRATIQUE
Utiliser les minuscules	Le champ id est toujours noté en minuscule.	id	ID
Possibilité d’ajouter le nom de la table avant l’identifiant pour avoir un champ plus clair.	Parfois le terme id est un peu juste. Il est souvent préférable d’ajouter un terme supplémentaire. Ce terme est séparé par un underscore.	Dans le cas où la table se nomme member, vous pouvez nommer le champ member_id	id_member full name
Justeìd. C’est tout.	Le terme id est suffisamment reconnu pour ne pas avoir besoin d’écrire “identifiant”.	id member_id	identifiant member_identifiant
Vous pouvez utiliser le terme pk	Dans le cas où id = clé primaire, alors vous pouvez utiliser l’abréviation pk	pk member_pk	pk_member primary_key_member member_primary_key

NOTE

👉 A noter : l’identifiant doit véritablement être unique. Par exemple, un nom n’est pas un élément unique (”Antoine Dupont” est certes un joueur de rugby unique, mais son nom est très commun en France et ne peut donc constituer un identifiant).

Champs dates

Pour les dates il convient d’être descriptif sur le nommage du champ.

MÉTHODOLOGIE	DESCRIPTION	BONNE PRATIQUE	MAUVAISE PRATIQUE
Le champ doit être descriptif	Décrire le champ date permet de mieux se repérer dans les champs de la table. La séparation de la description se fait avec des underscores uniquement.	start_date end_date current_month	date start-date
Utiliser l’anglais	Pour nommer le champ date vous devez utiliser l’anglais. Mais cela ne veut pas dire que la valeur du champ date est nécessairement une date formatée selon les standards américains ou anglais.	start_date end_date current_month	debut-date fin-du-mois

Champs booléens

Les champs booléens sont des champs qui ne peuvent prendre que 2 valeurs : true ou false.

MÉTHODOLOGIE	DESCRIPTION	BONNE PRATIQUE	MAUVAISE PRATIQUE
Utiliser un verbe		is_active is_send	active
Utiliser un underscore _ plutôt d’un espace ou un tiret	Séparer les termes par un underscore.	is_active	is-active
Utiliser l’anglais	Les termes à utiliser sont en anglais.	is_ready	est-prêt
❌ Ne pas utiliser d’accent, d’emoji, de ponctuation ou de guillemet	On ne met pas de ponctuation dans le nommage d’un champ	is_active	is_active? envoyé

Clé étrangère

Une clé étrangère permet de référencer une table depuis une autre table. Pour l’exemple, on va référencer la table content dans la table team_member.

Dans beaucoup d’outils no code, on peut utiliser des champs de type :

• Link to another record
• Lookup
• Rollup

WARNING

Ce type de liaison n’est possible dans le cas d’une relation 1:1 ou 1:n c’est-à-dire qu’une entité est peut être liée avec un ou plusieurs entités de la deuxième table.

MÉTHODOLOGIE	DESCRIPTION	BONNE PRATIQUE	MAUVAISE PRATIQUE
Utiliser le nom de la table de référence ainsi que l’identifiant de cette table.	Utilisez le nommage de cette manière : tablelinked_fieldname	Dans la table content, on aura donc team_member_id. Et dans la table team_member, on aura donc content_id Pour un lookup ou un rollup, vous pouvez utiliser également le même principe : content_name content_price team_member_count…	team_member content
Utiliser un underscore _ plutôt d’un espace ou un tiret	Séparer les termes par un underscore.	team_member_id content_id	team-member-id content-id
Utiliser l’anglais	Les termes à utiliser sont en anglais.	team_member_id content_id	equipe_id

TIP

Et dans le cas d’une liaison de plusieurs à plusieurs (n:n) il est préférable de créer une table de jointure. Une table de jointure contient :

• les clés étrangères des tables qu'elle relie. Ces clés étrangères correspondent aux clés primaires des tables liées
• Optionnellement, des colonnes supplémentaires qui fournissent des détails spécifiques sur la relation, telles que la date à laquelle la relation a été établie ou d'autres métadonnées pertinentes.

Exemple

Considérons que vous disposez des tables suivantes :

• author (author_id, name)
• book (book_id, title) Pour gérer une relation de plusieurs-à-plusieurs (many to many) entre ces tables (un auteur peut écrire plusieurs livres et un livre peut avoir plusieurs auteurs), vous créez une table de jointure appelée author_book :
• author_book (author_id, book_id, publication_date) Dans cet exemple, author_id et book_id sont des clés étrangères qui font référence respectivement aux tables author et book, tandis que publication_date est une information supplémentaire sur la date de publication du livre par l'auteur.