Discussion :

[ites]

Bonjour,

Je désirerais obtenir un tutorial ou des infos ou un conseil concernant "comment nommer ces champs" ?

ex:
table : ARTICLE
art_id
art_descr

Merci
Ites

[Swoög]

T'as pas du chercher énormément

je pense que ceci devrait t'aider ^^ : http://sql.developpez.com/normes/

[Alexandre T]

Je pense plutôt que ites parlait de la façon de nommer le champ code_article ou code_article, etc....

Voici les règles que je m'impose et qui facilite grandement mes requêtes :

Nom des tables :

• toujours en minuscule
• toujours au singulier
• toujours au masculin
• jamais d'accents
• si c'est une table de jointure (exemple les articles de la commande) table dans l'ordre alphabétique : article_commande
• jamais d'abreviations

Nom des colonnes :

• clef primaire : id_ + nom de la table
• libellé : lib_ + nom de la table
• date de creation de l'enregistrement : cre_ + nom de la table
• date de modification : mod_ + nom de la table
• description : des + nom de la table

Nom des index : ndx_ + nom table + nom_des_colonnes (abregé ssi > 64 caractères)

Voilà, je ne pense qu'il existe pleins de nomenclatures tout-à-fait valables. A mon sens une bonne règle est une règle simple qui gère un maximum de cas.

[ites]

Merci pour ton tuto mais ce n'est pas vraiment cela que je veux

En faites je désirerais:

ex:
soit
table PERSONNE (pers_id,pers_nom,pers_prenom,...)
ou soit comme ceci
table PERSONNE (id,nom,prenom,...)

Comment est il préférable de les nommer car dans tous les autres tuto on voit des exemples comme ceux-ci

Ites

[ites]

C'est ce que je cherchais, merci pour tes conseils Alexandre T.

et merci à vous deux

Ites

[Biglo]

Nom des colonnes :

• clef primaire : id_ + nom de la table
• libellé : lib_ + nom de la table
• date de creation de l'enregistrement : cre_ + nom de la table
• date de modification : mod_ + nom de la table
• description : des + nom de la table

Bonjour Alexandre,

Pourrais-tu expliquer brièvement tes choix de convention de nommage stp ? Ce qui m'intéresse surtout c'est la raison de l'ajout de "nom de la table" à chaque colonne. Un grand nombre de personnes nomme leur colonne de la même façon. Mais je n'ai jamais réussi à comprendre quel était l'avantage de suffixer chaque champ puisque les SGBD permettent de préfixer par le nom de la table et du schéma.

Une table, un schéma ou une base sont en quelques sortes des "espaces de noms".

Le seul avantage que je vois est que cette convention permet souvent des jointures naturelles, et donc une syntaxe SQL plus légère.

De mon côté, je trouve qu'avoir des noms de colonnes identiques (id, libelle) pour la plupart des tables facilite grandement les traitements automatisés tels que la génération de formulaires.

[Alexandre T]

Je fais cela pour

• la modélisation des données
• pour éviter les confusions lors de la réalisation de requêtes
• pour les outils de reporting qui assiste l'utilise et proposent eux même les jointures

Admettons que j'ai une entité ecole et une entité classe. Chaque classe appartient à une école.
Avec ma méthode :

• ecole : id_ecole,lib_ecole
• class : id_classe,lib_classe,id_ecole

Avec une méthode proposant les mêmes noms :

• ecole : id,lib
• class : id,id_ecole,lib

Si pour mon modèle je décide de modifier la colonne id_ecole pour la passer de entier à entier strinctement positif. J'ouvre mon dictionnaire de données dans mon outil, je change le champ id_ecole.

Avec l'autre méthode, l'outil peut provoquer des effets de bord et changer tous les champs id !

Autre point la liste des classes par écoles , cela donne :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
SELECT c.id_classe, c.lib_classe, e.id_ecole, e.lib_ecole 
FROM classe c
INNER JOIN ecole e ON e.id_ecole = c.id_ecole

Avec l'autre méthode cela donne :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
SELECT c.id,c.lib,e.id,e.lib
FROM classe c
INNER JOIN ecole e ON e.id = c.id_ecole

Le nom des champs dans la première requêtes expliquent clairement ce qu'ils représentent !
Dans la seconde requête j'ai deux id et deux lib.... Pas facile de discerner ceux de l'école de ceux de la classe, sauf si on passe par des alias...

Troisième point si on utilise un outil de reporting comme chrystal report ou infomaker.
Dans mon cas, je sélectionne les 4 colonnes des deux tables et Infomaker fait la jointure automatiquement. La requête SQL sera :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
SELECT classe.id_classe, 
       classe.lib_classe, 
       ecole.id_ecole, 
       ecole.lib_ecole 
FROM classe 
INNER JOIN ecole  ON ecole.id_ecole = classe.id_ecole

Avec la "mauvaise" méthode, j'aurais :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
SELECT classe.id, 
       classe.lib, 
       ecole.id, 
       ecole.lib 
 FROM classe 
 INNER JOIN ecole  ON ecole.id = classe.id

Voilà pourquoi

[Biglo]

Ok merci pour la réponse.

En effet, le suffixe est justifié pour l'utilisation d'outils de modélisation et de reporting. Pour la lisibilité, je ne suis pas convaincu, mais cela reste une affaire de goût

[SQLpro]

Lisez l'article que j'ai écrit sur le sujet :
http://sqlpro.developpez.com/cours/standards/

A +

[Mogwaï]

Je me permets de déterrer ce topic car je suis confronté à ce qui est pour moi un problème de nommage concernant les tables et les champs d'une base de données d'un projet sur lequel je travaille.

La convention utilisée est celle de Alexandre T : chaque champ reprend le nom de la table et pour les tables d'associations on a la liste des tables concernées dans le nom de la table.

Pour ma part, en pratique, c'est une horreur !

On a des tables d'association qui lient jusqu'à 5 tables. On se retrouve avec des nom de table à rallonge qui ne veulent finalement rien dire et qui pourraient se résumer en un seul mot. Et on a par dessus le marché des noms de champs interminables : jusqu'à 60 caractères.

Ajouté à celà, nos classes (PHP) qui traitent ces tables reprennent comme nom de méthodes d'accès aux attributs les même noms.

Je pense, et c'est ce que j'ai toujours fait sans problème, qu'il faut trouver un nom de table le plus simple possible et idem pour les noms d'attributs. Les arguments avancés par Alexandre T ne me semblent pas valables, puisque dans cet exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
SELECT c.id,c.lib,e.id,e.lib
FROM classe c
INNER JOIN ecole e ON e.id = c.id_ecole

On peut très bien s'en sortir ainsi :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
SELECT c.id AS id_classe, c.lib AS lib_classe, e.id AS id_ecole, e.lib AS lib_ecole
FROM classe c
INNER JOIN ecole e ON e.id = c.id

Toutefois je pense que pour les id, il faut reprendre le nom de la table, c'est un cas particulier.

Le pire, bien entendu, c'est que la personne qui a créé la base n'est pas celle qui l'utilise

Pour les outils de reporting, je ne peux pas me prononcer puisque je n'en utilise pas.

[CinePhil]

La méthode de SQLPro est bonne.
J'ai cependant pris une autre habitude avant de la découvrir alors je la propose aussi...

En partant d'une association de MCD :
Utilisateurs -0,n----Participer----0,n- Projets

Je transforme les entités en tables :
- Utilisateurs
- Projets
On remarque que le nom d'une table est au pluriel car elle contient plusieurs lignes. Même si on peu lire l'association : "Un utilisateur peut ou pas participer à plusieurs projets", Il y a bel et bien plusieurs utilisateurs dans la table. L'entité pour moi ne représente pas un seul utilisateur mais l'ensemble de tous les utilisateurs.

Je transforme l'association en table :
- soit en la nommant 'Participer' (verbe à l'infinitif) ;
- soit en la nommant 'UtiPrj' (abréviation mnémotechnique composée de lettres des tables entrant dans l'association) ;
- et depuis quelques temps j'aurais tendance à faire un mix des deux en la nommant 'U_P_Participer' (initiales des tables de l'association et verbe de l'association)

Passons aux colonnes des tables :
Je préfixe le nom de colonne de l'abréviation de la table choisie plus haut :
Utilisateurs(UtiId, UtiNom, UtiPrenom,...)
Projets(PrjId, PrjNom, PrjDateCreation, ...)
UtiPrj(UPUtilisateur, UPProjet, UPDateDebut, UPDateFin...)

Contrairement à SQLPRO, je préfère utiliser les minuscules mais je mets une capitale à chaque début de mot.
Ceci parce que je trouve qu'on voit mieux les noms des objets au milieu des requêtes avec les mots du langage en capitales.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
SELECT u.UtiNom AS Nom, u.UtiPrenom AS Prenom, p.PrjNom AS Projet
FROM UtiPrj up
INNER JOIN Utilisateurs u ON up.UPUtilisateur = u.UtiId
INNER JOIN Projets p ON up.UPProjet = p.PrjId
ORDER BY u.UtiNom, u.UtiPrenom

Certes, ici avec la coloration syntaxique on voit tout de suite la différence mais quand la requête est incluse dans une variable d'un programme PHP par exemple il n'y a plus qu'une couleur.

Je pense que je vais adopter progressivement la norme de SQLPro mais avec mon système 'CapitaleMinuscules'.

[SQLpro]

L'utilisation d'un trigramme unique permet aussi de synthétiser l'écriture des colonnes des tables.

A +