Très souvent la construction de la base de données et de ses tables est le résultat d'une méthode d'analyse. Nous prendrons ici pour l'exemple la méthode Merise, basée sur le modèle entité-relation.
Dans cette méthode les mots nous orientent très souvent vers des entités, des objets de gestion alors que les verbes nous font percevoir plus facilement les relations qui existent entre ces objets. Exemple : "Les clients achètent des produits..." nous font sentir tout de suite que les mots clients et produits seront des objets de gestion –il y aura à gérer des clients et des produits– alors que le verbe acheter traduira la relation qui existe entre ces deux objets de gestion (entre les clients et les produits).
Je ne vais pas rentrer dans le détail des cardinalités dans cet exemple, mais il semble évident qu'un client pourra acheter plusieurs fois et qu'un type d'article pourra être acheté plusieurs fois, lui aussi. Nous avons donc une relation n-aire (les cardinalités maximales sont n. n = plusieurs fois) La relation se transformera donc en table, dite table de relation. En fait, cette table contiendra les achats des différents clients (ex: le client n° 2 a acheté le produit n° 15, etc...). Cet constat nous poussera presque spontanément à nommer cette table "Achats". La base de données contiendrait donc trois tables : "Clients", "Produits", "Achats".
Techniquement parlant, ce n'est absolument pas dérangeant. Pour ma part j'opterai systématiquement pour ces trois noms de table : "Clients", "Acheter", "Produits". Et ceci pour deux raisons :
Une base de données est ni plus ni moins qu'un ensemble de tables et ne correspond pas obligatoirement à une seule gestion. Dans la même base de données il est possible d'y mettre toutes les tables correspondant à une gestion commerciale (par exemple) et en même temps les tables qui pourraient être utilisées pour une gestion marketing. Rien n'empêche d'ailleurs à ce que certaines tables génériques (tels que départements, codes postaux) soient utilisables simultanément par les deux gestions. Lorsque le nombre de tables n'est pas trop important, cela est tout à fait possible et évite même d'avoir, comme dans le cas des départements et codes postaux de dupliquer les tables dans des bases de données différentes.
Il est donc très utile de préfixer les tables (gc_* pour la gestion commerciale, gm_* pour la gestion marketing, etc.). De ce fait, on peut savoir au premier coup d'oeil que toutes les tables commençant par gc_* relèvent de la même gestion. Pour ma part, les tables communes à plusieurs applications commencent par underscore sans préfixe (_*) mais ceci est mon choix à vous de trouver vos propres normes, le but est qu'elles vous permettent de comprendre tout de suite et d'éviter des erreurs.
Dans l'exemple ci-dessous :
mysql> show tables; +------------------------+ | Tables_in_lolo | +------------------------+ | ca_Adresses | | ca_Groupes | | gia_Categories | | gia_Clients | | gia_Communes | | gia_Comprendre | | gia_ComprendreProduits | | gia_Configuration | | gia_Estheticiennes | | gia_Fournisseurs | | gia_Marques | | gia_Medecins | | gia_MoyensPaiement | | gia_Payer | | gia_Produits | | gia_Seances | | gia_Soins | | gia_Specialites | | il_ConfigSite | | il_Mails | | il_Promotions | +------------------------+ 21 rows in set (0.00 sec)
gia_Clients : nom de table préfixé, écrit en minuscules, au pluriel (cette table contient LES clients) et avec capitale.
gia_Payer : nom de table préfixé, écrit en minuscule, verbe de la relation à l'infinitif et avec Capitale.
Ce sont mes règles de nommage. A vous de trouver les vôtres. Mais le fait de suivre des règles évite bien des erreurs car on sait avec exactitude, lors de la rédaction du code, comment les noms sont à rédiger.
