Le but de ce tutoriel est de prendre conscience du fait de bien nommer la multitude d'objets possibles dans une base de données afin d'offrir à cette dernière un développement durable et un entretien facile, même - et surtout –, si vous la construisez à plusieurs développeurs …
Certes, vous pouvez tout aussi bien construire des objets portant les doux noms de « Table 1 », « Requête 27 » ou « Formulaire 9 » sans que le programme en soit aucunement affecté. A vrai dire, le logiciel s'en fout, seul lui importe le fait que s'il est fait référence à « Requête 27 » dans un formulaire, un rapport ou autres procédures, ce nom précis ne devra pas changer d'un caractère sous peine de dysfonctionnement immédiat.
Je trouve cette raison suffisante pour donner à cet objet un nom parlant, définitivement.
Ne vous en faites pas trop non plus, si vous déterminez plus tard que le nom d'un objet ne convient pas, il sera toujours possible de rechercher, remplacer … Mais plus la base est aboutie plus les recherches seront longues, et comme ce travail est fastidieux, il vaut peut-être mieux y penser dès le début.
Chacun peut développer sa propre nomenclature. D'ailleurs, si votre projet est particulier c'est surement de bon aloi, n'hésitez pas à être inventif, mais - conseil d'ami - tenez bien à jour un glossaire pour pouvoir vous y référer plus tard, ou pour passer plus facilement « le bébé » à un autre développeur.
J'ai opté comme beaucoup pour une systématique basée sur des préfixes qui m'évite d'avoir trop à réfléchir au moment de la création des objets et à leurs références ultérieures (dans le code, par exemple).
1- Système de clef à deux ou trois caractères :
Plutôt que de vous assommer encore avec de longs blocs de texte, je vous propose plutôt une liste d'exemples qui, j'en suis certain, parleront d'eux mêmes :
Mes tables principales commencent toutes par « tbl » : tblClient, tblFournisseur …Celles qui permettent la relation « plusieurs à plusieurs » commencent par « trl » : trlDetailCommande, par exemple, est située entre tblCommande et tblProduit.Tous les champs de ma table tblClient commenceront par « clt » : cltID, cltPrenom, cltNom, …Le champ de jointure externe dans ma table tblCommande sera comRefClient, ainsi je saurai reconnaître les identifiants (ID), des champs externes qui y font référence (Ref)Les requêtes commencent par deux caractères génériques « rq », suivis d'un troisième désignant leur nature ou leur fonction : « rqs* » pour les requêtes sélection, « rqu* » pour les requêtes Mise à Jour (Update en SQL), ou bien « lst* » si elles doivent alimenter une ComboBox …De même les formulaires commencent par « frm », les rapports par « rpt », etc …Une ComboBox commencera par « cbo », à moins qu'elle ne serve de filtre, auquel cas « cbf ».Et ainsi de suite … Le seul point important à respecter est juste : Un préfixe = Une seule fonction2- Éviter les caractères spéciaux :
Notamment les espaces et les caractères accentués (é, ô …), ce qui permettra le cas échéant un portage de l'application plus facile sur un autre système, et évitera probablement des complications dans le code pour la suite du développement. Personnellement j'évite même de mettre des « s » à la fin des libellés pour me simplifier la vie en évitant le doute quand je code, même si j'espère fortement qu'il y aura plus d'un client dans tblClient !
3- A quoi ça sert tout ça ?
Simplement à s'y retrouver en cours de développement :
Imaginons que j'ai besoin dans mon formulaire frmFournisseur, d'un bouton destiné à rajouter un produit. Je le nomme « btOfrmProduit ». Dès lors je sais que c'est un bouton (bt) qui ouvre (O) le formulaire frmProduit. Et puis quand j'écris du code je retrouve son nom plus intuitivement et ce même nom me rappelle que ce sont les propriétés et méthodes de l'objet « Bouton » que je doit gérer. De plus si je passe mon application à mon ami ingénieur en chef qui a au moins Bac + 12, j'évite (quelques unes) des sévères remontrances quant à l'illisibilité de mon codage. Enfin si j'ai besoin de souffler et que j'y revient dans six mois, cette nomenclature me servira d'aide-mémoire …
- - - - -
J'en profite pour remercier le Génie et l'altruisme des développeurs d'OpenOffice.org, ainsi que Bernard Marcelly et Laurent Godard, qui avec leur livre m'ont mis plus facilement sur le chemin. Chapeau bas messieurs dames !
Merci d'avance également à quiconque saura me donner des conseils pour corriger ou compléter cette bafouille ...
Merci enfin à tous les acteurs du monde libre, dont les membres de ce forum qui me font progresser tous les jours.
