Donnez votre avis

Nomenclature : nommage des champs de base de donnée, et des variables

Posez votre question

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
Ajouter un commentaire

Commentaires

Commenter la réponse de malalam