Discussion :

[molesqualeux]

Amis developpeurs , y'a -t-il des normes , ou convention de nommage des champs d'une base de données? une doc officielle? PS : mes champs seront en anglais. merci.

[Graffito]

Rien de vraiment universel à ma connaissance. Sauf l'identifiant primaire qui se termine généralement par "Id" (exemple : "CountryId")

Pour MySQL, nous nommons les champs en mettant une majuscule au début de chaque mot (par exemple : "CountryCode").
Attention, la norme ORACLE serait plûtot case insensitive. Dans ce cas, le nom champ que nous choississons est "COUNTRY_CODE".

Sinon, il existe une norme Microsoft, mais elle me semble bien peu utilisée. Voir http://msdn.microsoft.com/en-us/libr...a3(VS.80).aspx

[SQLpro]

Voici la norme que j'utilise depuis des années :
http://sqlpro.developpez.com/cours/standards/

Plus complète :
http://www.sqlspot.com/Norme-de-developpement.html

J'ai démontré son utilité à de nombreuses reprises. Dernière en date :
http://blog.developpez.com/sqlpro/p7...ntion-help-to/

A +

[kedare]

Personnellement je procède toujours comme ceci:
TOUT en minuscule
Noms de tables au pluriel (ex: articles)
Clés primaires : id
Champs de Clé étrangères : {champ}_id (ex: author_id -> users)
Clés étrangères: fk_{table_source}_{champ_source sans _id}_{table_destination}_{champ_destination} (ex: fk_articles_author_user_id)
Indexes : idx_{type}_{table}_{champ} (ex: idx_btree_articles_author_id)
Sequences: seq_{table}_{champ} (ex: seq_articles_id)
Triggers: trg_{table}_{action} (ex: trg_articles_update_tsv)

Et la même logique pour tout le reste, je sais pas trop ce que vous en pensez ? C'est relativement simple et ca permet d'identifier rapidement la fonction et chaque objet

[SQLpro]

Personnellement je procède toujours comme ceci:
TOUT en minuscule
Noms de tables au pluriel (ex: articles)
Clés primaires : id
Champs de Clé étrangères : {champ}_id (ex: author_id -> users)
Clés étrangères: fk_{table_source}_{champ_source sans _id}_{table_destination}_{champ_destination} (ex: fk_articles_author_user_id)
Indexes : idx_{type}_{table}_{champ} (ex: idx_btree_articles_author_id)
Sequences: seq_{table}_{champ} (ex: seq_articles_id)
Triggers: trg_{table}_{action} (ex: trg_articles_update_tsv)

Et la même logique pour tout le reste, je sais pas trop ce que vous en pensez ? C'est relativement simple et ca permet d'identifier rapidement la fonction et chaque objet

Votre façon de faire viole deux éléments essentiels :
1) la norme AFNOR qui précise que dans un système d'information, toute information doit être identifié par un nom unique. Or une FK contient exactement les mêmes informations que la clef primaire qu'elle référence, c'est donc la même info et le même nom !
2) les outils de modélisation, et les dictionnaire de données qui considèrent de même, qu'un même nom signifie une même information. Autrement dit une colonne nommée "nom" dans une table personne et dans une table ville doit contenir le même information, ce qui dans votre cas n'est pas vrai.

Par exemple avec votre façon idiote de nomer les colonnes de FK vous ne pourrez jamais utiliser le NATURAL JOIN, ni utiliser un outil de rétro ingéniérie au niveau MCD !

En sus si je devais auditer votre base, je mettrais un zéro pointé sur le modèle de données, considérant que vous n'avez rien compris à l'utilité de cet outil qu'est la modélisation de données....

Enfin une table comporte de manière plus que générales plusieurs lignes Il n'y a donc aucun intérêt à singer la manière américaine de nommer ce genre de choses avec un pluriel. Car si d'aventure vos tables ne contenaient qu'une seule ligne alors il serait souhaitable d'éviter d'utiliser un SGBDR ! En sus, certains tables résultant d'une jointure, donc d'un verbe, j'imagine la bêtise de ce que donnerais des verbes pluralisés comme "contients", comportes (qui signifie d'ailleurs un singulier => 2e personne "tu"...), etc !

A +

[Oishiiii]

Je rejoins SQLPro sur le message précédent.
J'utilise d'ailleurs presque la même règle que lui pour préfixer mes objets.
t_ pour les tables, tj_ pour les "tables jointure", v_ pour les vues, tr_ pour les tables de référence, etc..

Il est très important de ne pas modifier le nom d'une colonne, qu'elle soit clé primaire ou clé étrangère.
Cela permet effectivement d'effectuer des jointures naturelles, ou d'utiliser la clause de jointure USING sur MySQL et de simplifier la lecture des requêtes.

tr_type_telephone(typ_id, typ_libelle) -- Portable, Fixe, Fax, etc.
t_telephone(tel_id, tel_num, typ_id)
t_client(cli_id, cli_nom, cli_prénom)
tj_client_telephone(cli_id, tel_id)

Code SQL :

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

1
2
3
4
5
6
CREATE VIEW v_client_telephone AS
   SELECT cli_id, cli_nom, cli_prenom, tel_num, typ_libelle
   FROM t_client
     NATURAL JOIN tj_client_telephone
       NATURAL JOIN t_telephone
         NATURAL JOIN tr_type_telephone

Difficile de faire plus simple.

Effectivement une table contient plusieurs lignes, comme une relation contient dans son corps un ensemble de n-uplet, le pluriel est inutile, tout comme dans nos SGBDR préférés où les types intégrés sont INTEGER, DATE, etc. au singulier.

De plus lorsque je lis une ligne d'une table, le singulier vient naturellement:

Le Client qui a pour identifiant 299 a pour nom DUPOND et pour prénom Pierre.

contrairement à:

Les Clients qui ont pour identifiant 299..

[kedare]

Votre façon de faire viole deux éléments essentiels :
1) la norme AFNOR qui précise que dans un système d'information, toute information doit être identifié par un nom unique. Or une FK contient exactement les mêmes informations que la clef primaire qu'elle référence, c'est donc la même info et le même nom !
2) les outils de modélisation, et les dictionnaire de données qui considèrent de même, qu'un même nom signifie une même information. Autrement dit une colonne nommée "nom" dans une table personne et dans une table ville doit contenir le même information, ce qui dans votre cas n'est pas vrai.

Par exemple avec votre façon idiote de nomer les colonnes de FK vous ne pourrez jamais utiliser le NATURAL JOIN, ni utiliser un outil de rétro ingéniérie au niveau MCD !

En sus si je devais auditer votre base, je mettrais un zéro pointé sur le modèle de données, considérant que vous n'avez rien compris à l'utilité de cet outil qu'est la modélisation de données....

Enfin une table comporte de manière plus que générales plusieurs lignes Il n'y a donc aucun intérêt à singer la manière américaine de nommer ce genre de choses avec un pluriel. Car si d'aventure vos tables ne contenaient qu'une seule ligne alors il serait souhaitable d'éviter d'utiliser un SGBDR ! En sus, certains tables résultant d'une jointure, donc d'un verbe, j'imagine la bêtise de ce que donnerais des verbes pluralisés comme "contients", comportes (qui signifie d'ailleurs un singulier => 2e personne "tu"...), etc !

A +

1) Tout les noms sont unique, je vois pas pourquoi une FK aurais un nom de PRIMARY KEY dans le modèle que j'utilise...

2) J'ai pas trop comprit, je vois pas pourquoi villes.nom et personnes.nom devraient contenir la même information... Les outils de modélisation c'est pour ceux qui aiment pas le SQL, c'est pas mon cas.

3) L'utilisation du pluriel est plus logique car la table contient rarement/jamais une seul ligne, quand j'ai besoin d'une seul ligne j'utilise (AS {Nom Singulier})

Bref j'ai toujours procédé comme ça, et ça n'a jamais gêné personne...

[SQLpro]

1) Tout les noms sont unique, je vois pas pourquoi une FK aurais un nom de PRIMARY KEY dans le modèle que j'utilise...

Même information = même nom : simple et obligatoire NORME AFNOR ! et tous les outils ingénieux respecte ce principe... Mais vous pouvez aussi rouler avec des roues carrées ou téléphoner avec des pots de yaourt reliés par une ficelle !

2) J'ai pas trop comprit, je vois pas pourquoi villes.nom et personnes.nom devraient contenir la même information...

Faites une simple vue et vous m'en direz des nouvelles... Je sais les vues c'est pas votre truc, ça sert aux beauf, vous vous êtes un pro contrairement à moi !

Les outils de modélisation c'est pour ceux qui aiment pas le SQL, c'est pas mon cas.

A ce niveau de bêtise j'ai bien du mal à ne pas rire !
Mais voyez vous partout ou je fais du conseil à plus de 1000 euros jour, lorsque je présente ce que fais Power AMC ou WInDesign, les techniciens constatent qu'ils auraient pu gagner plusieurs mois de boulot avec ce genre d'outils !

3) L'utilisation du pluriel est plus logique car la table contient rarement/jamais une seul ligne, quand j'ai besoin d'une seul ligne j'utilise (AS {Nom Singulier})

A ce niveau vous êtes libre de faire ce que vous voulez. Y compris n'importe quoi, ce qu'à l'évidence vous semblez parfaitement maîtriser... ce qui n'est visiblement pas le cas des bases de données qui ne se résument pas au simple langage SQL !

A +

[danidan75]

A l'attention de Frédéric BROUARD:
Ayant lu avec attention un certain nombre de vos tutoriels, qui m'ont appris de nombreuses choses, il m'était déjà apparu que vous aviez des avis très tranchés (ce qui est votre droit) et que vous les exprimiez parfois de façon assez... abrupte, dirons-nous.
Avoir des opinions, c'est une chose. Insulter ses interlocuteurs, c'en est une autre. Même si je suis d'accord avec le fond de votre propos, la forme est exécrable et ne le sert pas. Il y a un monde entre dire "vous avez tort" (ce qui n'est déjà pas très diplomatique) et "vous êtes décidément trop con".
Bref, un peu de retenue, ce serait bien.

[SQLpro]

Vous pourrez remarquer que dans mon message il n'y a pas d'attaque personnelle... Je constate que certains propos sont imbécile, cela ne signifie pas que la personne derrière ces propos l'est.
Il m'arrive aussi de dire des conneries, mais effectivement assez rarement dans mon domaine d'expertise !

A +

[Kozher]

J'ai lu les recommandations plus haut mais je vois pas encore trop l'utilité de mettre les noms de tables en majuscules (RDBMS ?)...et j'ai l'impression que le script SQL est moins lisible avec tout qui est en majuscules

Y at-il des recommandations de trigramme dans le cas de tables telles que : souscategorie (lié à categorie), souscompetence (lié à compétence), sousfamille (lié à famille) ?

Merci

[SQLpro]

L'usage des majuscule dans les requêtes permet de faciliter la lecture des codes imbriqués. Par exemple lorsque vous aurez à mélanger du SQL et du code client (C++, Java, PHP ou autre....) il est plus facile de repérer ce qui est du SQL (majsucule) et ce qui est du code client dans les listings.

A +

[CinePhil]

Puisque cette vielle file de discussion est réactivée, j'en profite pour faire quelques petites remarques...

1) Perso, j'écris les mots SQL en lettres capitales et les noms des objets de la BDD (tables, colonnes...) en minuscules. Il est ainsi facile, même au milieu d'un code en PHP ou java ou autre, de trouver le code SQL et de lire plus facilement la requête que lorsqu'elle est entièrement en capitales.

Exemple :

Code :

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

1
2
3
SELECT prs_prenom, prs_nom
FROM te_personne_prs
ORDER BY prs_nom, prs_prenom

C'est d'ailleurs ce que fait la mise en forme automatique de notre forum préféré pour le langage SQL, même si on écrit tout en minuscules.

2) J'avoue ne pas respecter le nom unique pour deux colonnes sémantiquement équivalentes car je préfixe toutes les colonnes du code mnémotechnique de la table à laquelle elle appartient. Je trouve que ça lève encore plus les ambiguïtés et facilite la lecture de la requête.

Exemple :

Code :

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

1
2
3
4
SELECT prj.prj_id, prj.prj_nom, prj.prj_id_responsable, 
  prs.prs_nom, prs.prs_prenom
FROM te_projet_prj AS prj
INNER JOIN te_personne_prs AS prs ON prs.prs_id = prj.prj_id_responsable

3) J'ai découvert récemment que le nommage de table commençant par t_ pose problème avec le framework java Seam pour générer les entités à l'aide de la commande Seam Generate Entities dans les JBoss Tools d'Eclipse.
Comme cet outil utilise Hibernate, peut-être en est t-il de même plus généralement avec Hibernate et tous les outils qui l'utilisent.

J'utilise maintenant la norme :
- te_ table issue d'une entité ;
- tj_ table de jointure issue d'une association ;
- th_ table fille dans un héritage.

[SergentHeinz]

Bonjour,

Je relance un vieux post mais je souhaiterais une précision sur la norme utilisée notamment par SQLpro.

J'aimerais connaître les nommage de clés étrangères référençant un identifiant lorsqu'il y en a plusieurs dans une table.

Imaginons que nous avons une table utilisateur (TS_USER_USR) avec un id "usr_id". Imaginons maintenant une table qui doit référencer 2 utilisateurs (par exemple "auteur" et "manager"). Nous ne pouvons évidemment pas utiliser 2xusr_id, quels serait dans ce cas le nommage utilisé ?

Serait-ce "usr_id_author" et "usr_id_manager" par exemple ?

Merci d'avance !

[CinePhil]

Regarde le point 2) de mon message juste au dessus du tien.

Code :

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

ON prs.prs_id = prj.prj_id_responsable

Voilà une ambiguïté levée par une sémantique claire du nom de la colonne clé étrangère.

[SergentHeinz]

erf oui au temps pour moi je n'avais pas vu ce détail. Merci pour ta réponse !

[datacell33]

Votre façon de faire viole deux éléments essentiels :
1) la norme AFNOR qui précise que dans un système d'information, toute information doit être identifié par un nom unique. Or une FK contient exactement les mêmes informations que la clef primaire qu'elle référence, c'est donc la même info et le même nom !
2) les outils de modélisation, et les dictionnaire de données qui considèrent de même, qu'un même nom signifie une même information. Autrement dit une colonne nommée "nom" dans une table personne et dans une table ville doit contenir le même information, ce qui dans votre cas n'est pas vrai.

Par exemple avec votre façon idiote de nomer les colonnes de FK vous ne pourrez jamais utiliser le NATURAL JOIN, ni utiliser un outil de rétro ingéniérie au niveau MCD !

En sus si je devais auditer votre base, je mettrais un zéro pointé sur le modèle de données, considérant que vous n'avez rien compris à l'utilité de cet outil qu'est la modélisation de données....

Enfin une table comporte de manière plus que générales plusieurs lignes Il n'y a donc aucun intérêt à singer la manière américaine de nommer ce genre de choses avec un pluriel. Car si d'aventure vos tables ne contenaient qu'une seule ligne alors il serait souhaitable d'éviter d'utiliser un SGBDR ! En sus, certains tables résultant d'une jointure, donc d'un verbe, j'imagine la bêtise de ce que donnerais des verbes pluralisés comme "contients", comportes (qui signifie d'ailleurs un singulier => 2e personne "tu"...), etc !

A +

Très bien, je le note.
Et la norme AFNOR, elle est payante ? Ou peut-on en avoir un résumé succinct ?
Power MAC encourage à avoir un "dictionnaire" de correspondance mot/abréviation (exemple, Produit devient PRDT dans un nom de table ou de colonne) si mes souvenirs sont bons. Est-ce le cas pour AFNOR ?

Merci d'avance,

Cdlt.

[lekunfry]

Votre façon de faire viole deux éléments essentiels :
1) la norme AFNOR qui précise que dans un système d'information, toute information doit être identifié par un nom unique. Or une FK contient exactement les mêmes informations que la clef primaire qu'elle référence, c'est donc la même info et le même nom !
2) les outils de modélisation, et les dictionnaire de données qui considèrent de même, qu'un même nom signifie une même information. Autrement dit une colonne nommée "nom" dans une table personne et dans une table ville doit contenir le même information, ce qui dans votre cas n'est pas vrai.

Par exemple avec votre façon idiote de nomer les colonnes de FK vous ne pourrez jamais utiliser le NATURAL JOIN, ni utiliser un outil de rétro ingéniérie au niveau MCD !

En sus si je devais auditer votre base, je mettrais un zéro pointé sur le modèle de données, considérant que vous n'avez rien compris à l'utilité de cet outil qu'est la modélisation de données....

Enfin une table comporte de manière plus que générales plusieurs lignes Il n'y a donc aucun intérêt à singer la manière américaine de nommer ce genre de choses avec un pluriel. Car si d'aventure vos tables ne contenaient qu'une seule ligne alors il serait souhaitable d'éviter d'utiliser un SGBDR ! En sus, certains tables résultant d'une jointure, donc d'un verbe, j'imagine la bêtise de ce que donnerais des verbes pluralisés comme "contients", comportes (qui signifie d'ailleurs un singulier => 2e personne "tu"...), etc !

A +

Le propos est excellent sur le fond mais idiot dans sa forme parce que les insultes et les qualificatifs "idiots", "imbéciles" n'apportent rien de pertinent!!!

Par contre si je tiens compte de vos remarques je peux vous dire 95% des bases de données que j'ai rencontré dans les projets même chez des gros comptes ne passent pas la moyenne lors de vos audits... Mais les DSI, Expert Tech et autre CP Techniques les plus pointilleux n'imposent les normes que vous présentez

En tout cas je vais de ce pas les adopter

[kedare]

Donc si je comprend bien, d'après ce que dit SQLPRO il faudrait utiliser des noms en français pour les tables ?...
C'est clairement ce que j'évite de faire, pour moi une base de données francisé est forcément de piètre qualité car coupé de l'international anglais. (Sur mes systèmes, TOUT est en anglais, que ça soit le langage des OS (serveur), tout ce que l'on peut trouver dans le code (nom de variables/fonctions/classes, en suivant les conventions strict du langage), les bases de données, etc.

[CinePhil]

Toutes les applications n'ont pas forcément vocation à s'internationaliser !

Dans la mesure où je travaille sur une appli française, destinée à des français et qui ne sera maintenue que par moi ou éventuellement par des collègues français, je ne vois pas pourquoi je m'emmerderais à écrire mes variables, objets, commentaires dans les programmes... en anglais.

Et puis si un jour un anglophone trouve mon appli intéressante et veut l'adopter, ben pour une fois, ce sera lui qui fera un effort de traduction ! Non mais !