Discussion :

[kevin254kl]

Bonjour à tous,

Sur un projet mysql qui importe un xml j'ai nommé mes tables en anglais, quelqu'un ma fais la réflexion que les tables champs devrait ressembler au xm en français
Quele est la best practice et pourquoi?

Merci

[SQLpro]

Si votre application est destinée à un public français quel est l'intérêt d'avoir un message d'erreur du genre :
"Erreur lors de l'insertion de la valeur 123 dans la table CustomerPractices"
pour des utilisateurs ne parlant pas anglais ???

Est-ce que vous pensez que cela va être utile d'embrouiller les utilisateurs avec un sabir qui leur est inconnu ???

A +

[CinePhil]

LA règle essentielle à respecter dans le nommage des tables, colonnes et autres objets de la BDD est de ne pas utiliser les mots réservés du langage SQL.
SQLPro propose une norme de nommage dont je me suis inspiré et que je trouve assez pratique.

Quelques exemples de tables :
te_personne_prs (prs_id, prs_nom)
tr_civilite_civ (civ_id, civ_abreviation, civ_libelle, civ_ordre)
th_personne_physique_pph (pph_id_personne, pph_id_civilite, pph_prenom...)
tj_prs_resider_adr_pra (pra_id_personne, pra_id_adresse, pra_id_type_adresse)

Avec cette méthode, la règle est forcément respectée.

[Artemus24]

Salut à tous.

Bonne année, bonne santé, mes meilleurs vœux pour l'année 2021.

Nous sommes en France, et votre application va s'adresser à des français.
Pourquoi mettre des termes abscons dans une langue qui ne sera compréhensible que par vous ?
Je sais que l'anglais choc moins, mais si c'était de l'arabe, du chinois ou encore du russe, dans leur alphabet, que diriez-vous ?

Je fais la distinction entre les tables et les vues.
Je préfixe par "t_" et par w_".
Pour les noms des tables et vues, j'en mets un seul (quand c'est possible), et au singulier.
Pour les noms de colonnes, j'utilise des abréviations en préfixe.
Par exemple, les colonnes de la table des factures commande par "fac_".
Ce qui fait qu'un préfixe désigne la table.
Pour le suffixe, j'utilise aussi des abréviation ou parfois un nom, mais toujours au singulier.
Je vais toujours du plus général au particulier.
Par exemple, dans la table du personnel, la colonne date de naissance, voire aussi la colonne lieeu de naissance :
--> t_per_naiss_date
--> t_per_naiss_lieu

"t_" parce que c'est une table
"per_" abréviation du nom de la table qui ici est la table du personnel.
"naiss_ abréviation qui a un rapport avec la naissance.
"date", date de la naissance.
"lieu", lieu de la naissance.

C'est ma façon de procéder.
Après chacun fait comme il veut, mais cela doit respecter quelques règles.
1) faites un dictionnaire des abréviations que vous allez utiliser.
2) chaque abréviation doit avoir un sens qui ne porte pas à confusion.
3) ne pas utiliser les accents, ni les majuscules.
4) vos abréviations ou vos noms doivent commencer par un lettre.
4) le nom de la table ou de la colonne doit être unique dans votre base de données.
5) ne pas utiliser le pluriel.
6) éviter des noms en rallonge. plus c'est court et mieux c'est.
7) le nom doit être compréhensible, même pour quelqu'un qui découvre votre base de données pour la première fois.

Le lien donné par CinePhil sur "la Normalisation des noms des objets des bases de données", et écrit pas SQLPRO est un excellent exemple de ce qu'il faut faire.

@+

[escartefigue]

@Artemus24 d'accord avec quelques détails supplémentaires en rouge dans le texte :

Après chacun fait comme il veut, mais cela doit respecter quelques règles.
3) ne pas utiliser les accents, ni les majuscules. plus généralement ni caractères spéciaux, ni diacritiques (accents, cédilles), ni ligatures (ae, oe)
4) le nom de la table ou de la colonne doit être unique dans votre base de données. A l'exception des FK pour lesquelles, au contraire, il est préférable d'avoir le même nom dans toutes les tables

Et ajouter :
9) ne pas utiliser des noms réservés SQL pour nommer les objets

J'ai numéroté 9) car il y a deux règles 4

[CinePhil]

4) le nom de la table ou de la colonne doit être unique dans votre base de données. A l'exception des FK pour lesquelles, au contraire, il est préférable d'avoir le même nom dans toutes les tables

Pas d'accord avec ton ajout !
Il y a notamment des cas où c'est impossible : lorsque qu'une table est référencée plus d'une fois par la même table. Cas typique : une table enfant avec une clé étrangère pour chaque parent.

L'avantage de mettre des noms différents aux colonnes clés étrangères est aussi de toujours savoir d'où vient la colonne dans une requête.
J'ai par exemple l'héritage suivant :
personne <--- personne_physique <---- etudiant

Colonnes :
- te_personne_prs.prs_nom ;
- th_personne_physique_pph.pph_id_personne ;
- th_etudiant_etu.etu_id_personne_physique.

Avec cette technique de nommage, je sais à la fois à quelle table appartient la colonne (à l'aide du trigramme) et même dans la plupart des cas à quelle table fait référence la clé étrangère (par le corps du nom de colonne).

Et ajouter :
9) ne pas utiliser des noms réservés SQL pour nommer les objets

Comme je l'ai mis dans ma première réponse : pour moi c'est LA règle essentielle. Je la mettrais donc en premier dans la liste. et en 2 je mettrais la règle numéro 3 de Artemus augmentée par Escartefigue.

[escartefigue]

Pas d'accord avec ton ajout !
Il y a notamment des cas où c'est impossible : lorsque qu'une table est référencée plus d'une fois par la même table. Cas typique : une table enfant avec une clé étrangère pour chaque parent.

En effet CinePhil et nous avons déjà parlé ensemble de ce cas particulier dans un autre sujet du forum schéma me semble-t-il.
Mais il reste une exception et dans le cas plus général, je maintiens qu'un nom unique pour une même colonne reste la meilleure pratique

[Artemus24]

Salut à tous.

plus généralement ni caractères spéciaux, ni diacritiques (accents, cédilles), ni ligatures (ae, oe)

J'aurai dû préciser la restriction des caractères entrant dans le nommage des tables et des colonnes.
Le jeu de caractères a utiliser est celui de la table ASCII, uniquement l'alphabet en minuscule et les chiffres.
Le seul caractère que j'utilise, en dehors de ce que je viens de dire est le souligné.

A l'exception des FK pour lesquelles, au contraire, il est préférable d'avoir le même nom dans toutes les tables

Je rejoins CinePhil à ce sujet.

Pour ma part, je reprends le même nom de la colonne qui sert de clef primaire dans la table mère, mais en tant que suffixe.
Afin d'être clair, j'ajoute un préfixe qui va indiquer deux choses :
--> l'appartenance à la table.
--> qu'il s'agit d'une clef étrangère.
Si je fais plusieurs fois référence à cette même colonne, je fais en sorte de ne pas avoir la même désignation de la clef étrangère.

Par exemple, la clef primaire se nomme "per_id".
Je sais que cette colonne désigne un identifiant de type technique dans la table "personnel".
Ce qui donne "adr_fk_per_id".

Si je fais plusieurs fois référence à la même clef primaire dans une table, il me suffit de remplacer "fk", par "fk1", "fk2" et ainsi de suite.

Ce qui revient à dire, qu'un nom de colonne doit être unique dans une base de données.
L'ambiguîté est de désigner par un même nom, des colonnes qui ont des usages différents.

9) ne pas utiliser des noms réservés SQL pour nommer les objets

Je réponds non à cette affirmation. Pourquoi ? Parce que cela n'arrive jamais.

Comme je l'ai dit, un nom de colonne est une construction de plusieurs abréviations, dont la principale est son préfixe.
Si le nom "date" est un mot réservé dans le SGBDR, il suffit de l'écrire avec son préfixe pour que cela ne soit plus le cas : "pers_naiss_date".

Comme tu le sais, il suffit de mettre le nom de la colonne entre les apostrophes inversées (touche alt gr + 6) pour que cette colonne ne soit pas interpréter par le SGBDR.

je maintiens qu'un nom unique pour une même colonne reste la meilleure pratique

Mon critère est bien de rendre chaque colonne unique dans la base de données.

Qu'est-ce qui t'empêche de faire l'usage de "PK" pour primary key ou de "FK" pour foreign key ?
Cela supprimer toute ambiguïté et donne un sens au nommage de tes colonnes.

@+

[SQLpro]

....
personne <--- personne_physique <---- etudiant

Colonnes :
- te_personne_prs.prs_nom ;
- th_personne_physique_pph.pph_id_personne ;
- th_etudiant_etu.etu_id_personne_physique....

Pour l'héritage pas d'accord du tout, car c'est la même clé et le principe de l'héritage est de permettre des jointures qui outrepassent les tables intermédiaires....

A +

[CinePhil]

Pour l'héritage pas d'accord du tout, car c'est la même clé et le principe de l'héritage est de permettre des jointures qui outrepassent les tables intermédiaires....

A +

Ça n'empêche rien. Comme l'identifiant de l'étudiant a la même valeur que celui de la personne physique dont il hérite et qui a la même valeur de la personne dont elle hérite, rien n'empêche de faire une jointure directement entre th_etudiant_etu et te_personne_prs.

De même que si etu_id_personne_physique (pk de th_etudiant_etu) est référencé par exemple par une table des inscriptions te_inscription_ins (ins_id, ins_id_etudiant...), si j'ai besoin de la date de naissance de l'étudiant, je peux me contenter d'une jointure entre te_inscription_ins et th_personne_physique_pph si c'est cette table qui stocke la date de naissance.

En résumé, le changement de nom de de colonne d'une clé à l'autre n'empêche pas les jointures traversant plusieurs tables.

[vanagreg]

Bonjour,

Je ne sais pas pour MySQL, mais moi je préfère nommer les objets de ma base de données en anglais. Qu'on le veuille ou non, c'est la langue internationale. Ce n'est pas parce qu'au départ l'application est pensée pour des utilisateurs français qu'il faut absolument nommer en français. Il faut voir grand. Un exemple tout simple : ma boite a été rachetée par des allemands. C'est con on ne parle pas allemand, donc on communique en anglais avec les nouveaux collègues. Je pense que pour eux ça aurait été plus simple pour eux d'avoir des conventions de nommage en anglais plutôt que le français.

D'autres raisons pour lesquelles l'anglais sera plus pratique:
- si tu soumets un ticket chez l'éditeur de la base de données, ce sera plus parlant pour l'analyste d'avoir des objets nommés en anglais qu'en français car ton ticket tu devras l'ouvrir en anglais
- Idem pour les forums d'entraide, tu toucheras un public beaucoup plus large si tu écris en anglais plutôt qu'à te limiter en français

Je parle des objets (noms de tables, de programmes, etc.) qui sont transparents pour l'utilisateur final. Je ne parle pas des libellés qui eux bien sûr peuvent être en français (voire multilingues si ton appli le prévoit).

Cela dit, j'ai tellement vu de nommages dégueulasses en anglais qu'au final je préfère encore que les développeurs utilisent le français. Car déjà quand tu écris en anglais "informations" ou "datas" alors que ce sont des mots indénombrables en anglais, c'est mal parti.

[manzeki]

Bonjour à tous,

Sur un projet mysql qui importe un xml j'ai nommé mes tables en anglais, quelqu'un ma fais la réflexion que les tables champs devrait ressembler au xm en français
Quele est la best practice et pourquoi?

Merci

Je nomme mes objets de telle sorte qu'ils soient lisibles pour moi et pour les autres développeurs dans 2, 3ans ou plus.
J'évite les abbréviations, j'écris litteralement, le plus simplement du monde et tout en minuscule
Nom de Tables et vues : tout en minuscule, underscore uniquement, et au pluriel
Nom de colonnes : tout en minuscule, underscore, et au singulier
Nom de fonctions : tout en minuscule, underscore, et au singulier

Je préfixe rarement mes colonnes par des tb_... ou table..machin.
Je trouve cela inutile. On est déjà dans une table pourquoi préfixer un nom de table par

Code :

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

tb_...

En plus les outils d'administration affichent les objets par vues, tables, fonctions....

Au lieu de préfixer, je regroupe mes tables dans des schemas (exemple facture, contacts, ....)

Exemple, au lieu de empls ou tb_employes..., j'opte simplement pour employes
Je mets tout en anglais, l'informatique étant elle même en anglais
Et surtout que mes clients sont à l'international

[Artemus24]

Salut Manzeki

Je préfixe rarement mes colonnes par des tb_... ou table..machin.

Comment fais-tu la différence entre la vue et la table ?

Je mets tout en anglais, l'informatique étant elle même en anglais
Et surtout que mes clients sont à l'international

Au Canada, vous êtes bilingues dès la naissance, ce qui n'est pas le cas en France.
Pour toi, l'international, ce sont les Etats-Unis.
Pour nous, l'international, ce sont des pays comme l'Espagne, l'Italie, la Grande-Bretagne, l'Allemagne, la Pologne, ... enfin je veux dire les pays de l'Europe.
Autant de langue, en France que nous ne maitrisons pas nécessairement, voire même pas du tout.

Je nomme mes objets de telle sorte qu'ils soient lisibles pour moi et pour les autres développeurs dans 2, 3ans ou plus.

Ce qui implique que tes autres développeurs connaissent le français et l'anglais. Au Canada, je comprends.

Mais en France, bien que les développeurs soient de plus en plus souvent bilingues, ce n'est pas toujours le cas.
Désolé de le dire, mais en France, la langue officielle est le français, pas l'anglais.

@+

[escartefigue]

Bonjour,

Il y a des sujets pour lesquels utiliser l'anglais ne présente aucun intérêt : la paye ou la retraite par exemple sont des sujets strictement nationaux, la règlementation étant spécifique à chaque pays.

Pour rechercher de l'aide sur les forums que les tables s'appellent "CUSTOMER" ou "CLIENT", "ORDER" ou "COMMANDE" ne change rien.
Les solutions SQL restent les mêmes, seule l'explication du contexte et l'argumentaire devront être rédigés en anglais, dans certains cas (ce n'est pas nécessaire sur developpez.net qui est francophone )

De plus, utiliser des termes en anglais augmente le risque de percussion avec des mots réservés SQL, attention donc si aucune règle de nommage n'est utilisée

Enfin, en entreprise, les règles de nommage sont souvent contraintes, il n'y a guère que pour un usage privé qu'on peut choisir librement la nomenclature appliquée.