Générateur de noms de tables de base de données

Lire la table avant les colonnes

Le nom d’une table est répété partout où les données circulent : code applicatif, SQL, migrations, tableaux de bord, rapports d’incident et discussions. Cette répétition en fait un choix d’architecture. CustomerContactDetails doit identifier directement les lignes. UserRoleAssignments rend la relation elle-même visible. SchemaMigrationLocks indique au contraire un mécanisme de coordination plutôt qu’un objet métier.

Faire correspondre le nom au cycle de vie

Le cycle de vie fournit souvent le qualificatif décisif. PaymentEvents suggère un historique ajouté sans réécriture. DailySalesRollups désigne des agrégats dérivés. StagedCustomers évoque des imports en attente de validation. ArchivedCustomerRecords avertit que les lignes ne sont plus actives. CacheInvalidationEvents concerne la coordination de données dérivées, tandis que DataErasureRequests porte des attentes de confidentialité et de workflow. N’employez ces termes que si les contraintes et les pratiques d’écriture les rendent exacts.

Associer vocabulaire métier et précision technique

Les bons noms relient le vocabulaire du produit à la structure de la base. Utilisez les termes compris par le support, la finance, les opérations et l’analytique, puis ajoutez un qualificatif technique uniquement lorsqu’il résout une ambiguïté réelle. InvoicePaymentAllocations convient si l’allocation est une action à part entière. CountryCodes suffit pour un petit référentiel. TenantNotificationRules est juste si chaque ligne appartient à un locataire. Évitez les numéros de version et les noms de services temporaires.

Contrôle rapide du nom

• Nommer d’abord l’entité ou l’événement central.
• Réserver Logs, Events, Audits et History à des cycles de vie réellement différents.
• Appliquer la même logique à toutes les tables de liaison.
• Employer Staged, Cached, Archived ou Rollup seulement lorsque le qualificatif est exact.
• Préférer les noms métier stables aux détails d’implémentation provisoires.

Questions avant la prochaine migration

Testez chaque proposition dans une jointure, un titre de migration et une alerte. Vérifiez qui possède les données, si elles représentent l’état ou l’historique, et si une table voisine utilise déjà le même nom. Choisissez ensuite la forme la plus courte qui conserve ces distinctions.

• Que déduirait une personne d’astreinte à partir du seul nom ?
• Quel mot distingue cette table de sa voisine la plus proche ?
• Le nom fonctionne-t-il encore si la fonctionnalité actuelle est remplacée ?
• Quelle contrainte ou quel cycle de vie devrait être suggéré discrètement ?