Discussion :

[sebpern]

bonjour
je voulais savoir les règles pour nommer mes champs
ex :
client(idClient,nomClient, ...)
commande(idCommande, dteCommande, FK_idClient)
ma question est surtout sur le nom de la clé etrangere
FK_idClient ou idClient
d'où je pourrais faire un jointure naturelle (NATURAL JOIN ) en SQl ou non ?
Merci

[sebpern]

client, clients ?

existe t il avec merise une norme merci

[CinePhil]

Une table est composée de colonnes et de lignes, pas de champs.
Une entité d'un MCD Merise est composée d'attributs.

Il est d'usage de nommer les entités du MCD, lesquelles deviendront des tables, par des noms au singulier.

Il n'existe pas à ma connaissance de norme officielle pour nommer les objets des bases de données.
Tu peux créer tes propres règles si aucune ne t'est imposée en lisant cet article de SQLPro

[wiztricks]

MERISE, je ne connais plus mais comme vos "identifiants" auront une portée plus générale que le modèle de données. Je peux vous faire partager quelques réflexions.

Il n'y a pas de règles mais peut être quelques usages essentiellement dictés par:

- la lisibilité des éventuelles requêtes SQL qu'on va faire sur la base... Et le fait que nous allons utiliser des identifiants construits avec des mots "composés". Pour discerner ces mots: CamelCase: ClientId ou séparation par '_': client_id

- des contraintes sur les identifiants des langages de programmation utilisés, i.e. il n'est peut être pas judicieux de donner CLIENT-ID à un attribut/colonne/champ, s'il faut l'écrire CLIENT_ID ou CLIENTID pour désigner la chose dans le langage..

Note: A mon sens s'il est illusoire de rechercher une égalité entre les identifiants des différentes représentations (classes, tables, ...), éviter d'avoir des tables de correspondances en ayant des règles de transformation simples.... Ou vous dire que potentiellement ClientID, CLIENT_ID, ClientId, client_id doivent correspondre à la même chose.

- le langage utilisé. Si vous utilisez VB qui n'est pas typé, peut être est-il utile de préfixer l'identifiant par le type: SZ, DT,...

Voilà en gros les questions à résoudre mais les réponses sont très subjectives
Par exemple, lorsque vous écrivez:

• client(idClient,nomClient, ...)
• commande(idCommande, dteCommande, FK_idClient)

pleins de choses choquent mon regard.
Je peux essayer de vous expliquer pourquoi et vous, avoir de très bonnes raisons pour l'ignorer.

Exemple:

• idClient, idCommande: s'il est métier je l'appele Ident, si c'est technique ce sera plutôt ID éventuellement préfixé par U, O ou UU.

Note: En général une table à une PK simple, dans le cas composite, c'est plus galère mais "Ident" a une propriété générique à presque toute vos tables: c'est la clé qui vous permet de construire la relation d'identité. Pas de bonne raison qu'elle ait un nom bizarre pour chaque table.

• Clients ou clients plutôt que client: sémantiquement Clients est l'ensemble des clients (mais seulement pour le nom des tables).

• client(idClient,nomClient, ...): pourquoi suffixer l'identifiant par 'client' alors que Client.ID, Client.nom, ... vous donne déjà une structure hiérarchique simple permettant de préciser le cas échéant.

=> Clients(ID, nom,...) pour le schéma
=> Client.ID, Client.nom les attributs d'un uplet 'Client'

• Nom composés. nomClient ou ClientNom; idClient ou ClientID: utiliser le nom de l'entité en préfixe plutôt que celui de l'attribut. C'est cohérent avec la régularité de la hiérarchie précédente. Utiliser '_' comme séparateur me convient mieux visuellement mais il y a des règles simples pour naviguer entre ClientNom et client_nom

• FK_idClient pourquoi de pas se contenter de 'Client', i.e Commande.Client relie la commande au Client. Si vous voulez être plus précis, Commande.ClientIdent ou Commande.ClientID disent la même chose mais avec une contrainte différente sur la réalisation.

-W