Discussion :

[noname_971]

Bonjour tout le monde,

J'essaie de créer une base de donnée pour mon entreprise afin de pouvoir gérer un projet.

[code]
T_Site(Id_Site, Site)
T_Commande(Numero_Machine,#Id_Type,#Id_Site,Date_commande,Date_Prevue)
T_Instalallation(Id_Installation,Date_installation,Remarque)
T_Type(Id_type[/y},Type)
T_Mouv(Id_Mouv,Numero_Machine,Date_Mouv)

[Kloun]

Et ?

[cafeine]

Hello,

merci d'éditer ton message pour y mettre un titre clair et précis et formuler une question tout aussi précise ...

[random]

c'est assez stupide de nommer une table t_site
site suffit largement sous access

[snoopy69]

c'est assez stupide de nommer une table t_site
site suffit largement sous access

Voici la nommenclature que j'utilise :

TB_PERSONNES --> Nom de la table : Toujours en majuscule et au pluriel
pk_personne --> Clé primaire de la table. PK pour primary key
nom_personne --> Le nom du champ avec un "_" puis le nom de la table
vec un "_" puis le nom de la table
prenom_personne
fk_ville_personne --> Clé étrangère de la table TB_VILLES. FK pour Foreign Key

TB_VILLES--> Nom de la table : Toujours en majuscule et au pluriel
pk_ville--> Clé primaire de la table. PK pour primary key
nom_ville --> Le nom du champ avec un "_" puis le nom de la table
np_ville --> Le nom du champ avec un "_" puis le nom de la table

Attention je vois que tu as des champs DATE !!! Je voulais juste préciser qu'il est important de ne pas nommer un de tes champs DATE ... mais tu peut utiliser ce mot malgré tout en le concaténant c'est à dire :

Date_naissance
DateNaissance

[random]

Snoopy tu fais ce que tu veux
je ne suis pas contre la normalisation

mais
TB_PERSONNES --> Nom de la table : Toujours en majuscule et au pluriel
pk_personne --> Clé primaire de la table. PK pour primary key
nom_personne --> Le nom du champ avec un "_" puis le nom de la table
vec un "_" puis le nom de la table

me semble assez grotesque malgré les normes en usages
toujours en majuscules c'est bien au pluriel si on veut mais
qu'apporte tb_ ?? rien à mon sens sauf une frappe plus longue un peu moins de visibilté dans les requêtes

pour nom_personne c'est pareil nom suffit largement

je suppose que tu nommes tes formulaires formulaire_nomformulaire
et tes pages d'accès aux données page_d'acces_aux_donnees_nom

pour moi c'est du charabia et il serait temps de revisiter ses normes héritées de logiciel disparus

je conseillerais toujours de donner des noms courts mais évocateurs sans _ c'est un problème de productivité d'autant que l'interface livré doit masquer la représentation interne

par contre on peut se focaliser sur les procèdures de documentation et je préfère investir dans les commentaires des champs que sur des noms à rallonge

[snoopy69]

Ce devient du débat ... lol ... ... non personnelement je pense que la nomenclarture est propre à chaque personne et qu'il faut utiliser une nommenclature avec laquelle on se sent bien et avec laquelle on retrouve tout ce que l'on chercher quand on en a besoin ...

Random dit :

TB_PERSONNES --> Nom de la table : Toujours en majuscule et au pluriel
pk_personne --> Clé primaire de la table. PK pour primary key
nom_personne --> Le nom du champ avec un "_" puis le nom de la table
vec un "_" puis le nom de la table

me semble assez grotesque malgré les normes en usages
toujours en majuscules c'est bien au pluriel si on veut mais
qu'apporte tb_ ?? rien à mon sens sauf une frappe plus longue un peu moins de visibilté dans les requêtes

Pour moi le "TB_" signifie que c'est une TABLE et c'est pratique dans les recherches je trouve car si tu nomme une TABLE personnes et que tu créer un formulaire sur cette table pour ajouter des personnes par exemple et que tu nommes sans faire attention ton formulaire personnes ben cela donne un peu du charabia ... ... ... je sais pas si tu vois ce que je veux dire ...

Random dit :

pour nom_personne c'est pareil nom suffit largement

La je ne suis pas trop d'accord avec toi car si tu prends un exemple tu as une TABLE TB_PERSONNES et tu mets le champ nom dedans et que par la suite tu veux créer une table TB_ANIMAUX par exemple un animal (pour autant qu'il soit domestique ) il a un nom donc tu vas mettre comme champ nom et tu auras des conflicts tout dépend ce que tu fais si tu ne précise pas de quelle table fait partie le champ nom ... tu me suis ???

Random dit :

je suppose que tu nommes tes formulaires formulaire_nomformulaire

Non mes formulaire je les nommes : FRM_

Mes etats je les nommes : ETA_

Mes modules je les nommes : MOD_

Mes macros je les nommes : MAC_

Mes requêtes je les nommes : REQ_

Random dit :

je conseillerais toujours de donner des noms courts mais évocateurs sans _ c'est un problème de productivité d'autant que l'interface livré doit masquer la représentation interne

La je suis d'accord sur le point que des noms cours c'est pratique ... il n'y a pas de soucis ...

Random dit :

par contre on peut se focaliser sur les procèdures de documentation et je préfère investir dans les commentaires des champs que sur des noms à rallonge

Là, je suis entièrement d'accord avec toi ... ...

[random]

tu as raison ce sont des convenances perso

je craignais simplement que ce soit un système de normes

il se trouve que certains informaticiens préconisent et essayent parfois
d'imposer ces normes

c'est défendable pour un travail d'équipe mais je m'y refuse à titre individuel

malgré cette absence de normalisation je t'assure que si l'âne de monsieur Noé se nomme Martin il ne m'est jamais arrivé de confondre
[animal]![nom] et [personne]![nom]

ainsi bien qu'à contrario tu aies choisi un pseudo d'animal j'ai mis ton item
dans la table des personnes :D