Nomenclature : nommage des champs de base de donnée, et des variables
Nomenclature : nommage des champs de base de donnée, et des variables
C'est quoi ?
C'est l'ensemble des règles de nommage qui permet de ne pas se noyer dans une appli, quelle qu'elle soit.
C'est ma manière de travailler, et elle est fluide à l'usage, même pour les autres participants. Il faut juste prévoir un peu. Mais c'est indispensable en Info...
BdD
Sur le nom des tables
Peu de choses, juste ajouter un préfixe relatif à l'utilisation des tables.
Les tables de Références (liste de trucs, etc.) : préfixe : REF_
Celles de Fonctionnement (messagerie, table des traductions en site multi-lingue, etc.) : préfixe FON_
Toutes les autres, sont normalement les tables centrales de l'utilisation de l'appli, pas de préfixe.
Ne pas oublier pour le nom de la table, qu'il n'y a que 26 lettres dans l'alphabet, et rares sont les tables ZORRO ou XYLOPHENE. Par contre, y'a beaucoup de P (PERSONNAGE, PERSONNEL, PERSONNE, FON_PROFIL, REF_PAYS, etc.). Autant que faire ce peut, au regard de la règle de nommage des champs, éviter les initiales identiques (sauf pour des types de table différents).
Avantages :
- D'un coup d'oeil vous savez retrouvez votre table dans le BO de la BdD.
- Lors de la création d'une requête, vous savez quelle est le nom de la table a utiliser.
Inconvénient :
Il faut y réfléchir avant. Mais est-ce un inconvénient au vu du temps gagné après.
Les champs
Là il y a du boulot.
A peu de chose près toujours avoir dans une table :
- un champ ID, clef primaire unique en auto-incrément.
- un champ LIB, qui fini toujours par avoir son utilité (liste, BO, etc.)
- puis les autres?
Nommage : préfixer les champs par les initiales de la table :
- P_ID, pour l'id de la table PAGE
- R_P_LIB, pour le libellé de la table de référence REF_PAYS
- F_P_DATEIN, pour la date de la table de fonctionnement FON_MESSAGE
Avantages :
- Lors de la création d'une requête en cours de dév., vous ne pouvez plus avoir de doute sur le champs à appeler.
- SQL ne s'emmêlera pas les pinceaux entre ID et ID (celui de USER et celui de FON_CONNEXION).
Inconvénient :
Il faut y réfléchir avant. Mais est-ce un inconvénient au vu du temps gagné après.
PHP
(et autres ?)
Le préfixe ça marche, on continue donc.
Comme vous ne pouvez pas toujours connaître (ou contrôler) l'état de REGISTER_GLOBAL de votre hébergeur, autant prendre ses précautions pour éviter que $_SESSION['nom' * prenne la valeur de $nom...
Donc :
- variable de session : préfixe 's_'
- variable passée en get : préfixe 'g_'
- variable passée en post : préfixe 'p_'
- autres, vous aurez compris,
- variable courantes : ne pas avoir des noms trop long, mais faire un nommage selon l'usage de l'objet manié. Différence en $cout (de l'article) et $cout (de mon panier). Si j'ai ce cas de figure, autant tout de suite les nommer $cout_art et $cout_pan.
Avantage :
Lors de la création d'une requête ou d'un test en cours de dév., vous savez toujours quel est le nom de la variable à utiliser.
Inconvénient :
Là encore il faut y réfléchir avant. Mais est-ce un inconvénient au vu du temps gagné après, surtout en recherche de debug lié à un conflit de nom de variable
Voilà, sans prétention. Evident pour moi, mais apparemment pas pour tout le monde...
Tartuffe
- Nomenclature base de données
- Base de données javascript - Conseils pratiques -Javascript
- Récupérer données json (javascript) - Conseils pratiques -Javascript
- Connexion base de données - Conseils pratiques -PHP
- Base de données stock ✓ - Forum Visual Basic
- Connecter une application android à une base de données - Conseils pratiques -Java
10 août 2019 à 11:44