Une page, pas un guide
La convention que personne ne lit est celle qui fait dix pages.
Une convention de nommage n'a qu'un objectif : qu'une personne qui découvre la base de données comprenne ce que contient une table ou une colonne sans ouvrir la documentation. Pour y parvenir, quelques règles suffisent, à condition de les appliquer partout.
Les règles que nous appliquons
- Une seule langue. Tout en anglais ou tout en français, mais jamais un mélange : customer_orders ou commandes_clients, pas client_orders.
- Des minuscules et des tirets bas. purchase_orders, pas PurchaseOrders ni PURCHASE-ORDERS. Les moteurs de bases de données ne traitent pas tous la casse de la même façon ; les minuscules évitent toute surprise.
- Des noms au pluriel pour les tables. Une table contient des lignes : customers, invoices. La convention inverse se défend aussi ; l'essentiel est de choisir et de s'y tenir.
- Une clé primaire nommée id, et des clés étrangères nommées d'après la table visée : customer_id pointe vers customers. On lit la relation sans consulter le schéma.
- Pas d'abréviations maison. qty_rcv_dt économise dix caractères et coûte dix minutes à chaque lecteur. received_at se comprend tout seul.
- Des suffixes qui disent le type. _at pour une date et une heure (created_at), _on pour une date seule, is_ ou has_ pour un booléen (is_active), _count pour un nombre, _amount pour un montant.
- Des tables de liaison nommées d'après les deux tables, au singulier et par ordre alphabétique : product_supplier.
Les détails qui font la différence
- Les index et les contraintes portent un nom explicite : idx_invoices_customer_id, uq_users_email. Le jour où une contrainte bloque une insertion, le message d'erreur dit immédiatement laquelle.
- Les colonnes de statut ont des valeurs lisibles : pending, paid, cancelled plutôt que 1, 2, 3. Un code numérique oblige chacun à garder une table de correspondance en tête.
- Les unités figurent dans le nom quand elles ne sont pas évidentes : weight_kg, duration_minutes, amount_gnf. Personne n'a à deviner si un montant est en francs guinéens ou en dollars.
Pourquoi c'est rentable
Chaque règle paraît anodine. Ensemble, elles changent le quotidien. Les requêtes s'écrivent sans consulter le schéma. Les erreurs de jointure se repèrent à la lecture. Les outils de visualisation et les frameworks devinent correctement les relations. Et une personne qui arrive sur le projet devient autonome en quelques jours plutôt qu'en quelques semaines.
À l'inverse, une base sans convention accumule les variantes : client, clients, tbl_customer, CustomerData, parfois pour désigner la même chose. Chaque variante est une question posée à un collègue ou, pire, une supposition.
Et l'existant ?
Inutile de tout renommer d'un coup : c'est risqué et rarement prioritaire. Nous appliquons la convention à tout ce qui est nouveau, et nous renommons l'existant au fil des évolutions, quand on touche de toute façon à la table concernée. Des vues correctement nommées peuvent aussi servir de façade propre au-dessus d'un ancien schéma, le temps de migrer.
On nomme une table comme on nomme une variable dans un code bien écrit : pour le prochain lecteur, pas pour soi.
La convention complète tient sur une page. Imprimez-la, affichez-la, et faites-la vérifier lors des revues de code : c'est le moyen le plus simple de la voir respectée.