Publicité
+ Répondre à la discussion
Page 1 sur 2 12 DernièreDernière
Affichage des résultats 1 à 20 sur 35
  1. #1
    Débutant
    Inscrit en
    novembre 2004
    Messages
    268
    Détails du profil
    Informations forums :
    Inscription : novembre 2004
    Messages : 268
    Points : 99
    Points
    99

    Par défaut Conventions de nommage d'une base de données

    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.
      1  0

  2. #2
    Expert Confirmé Sénior Avatar de Graffito
    Inscrit en
    janvier 2006
    Messages
    5 805
    Détails du profil
    Informations forums :
    Inscription : janvier 2006
    Messages : 5 805
    Points : 6 694
    Points
    6 694

    Par défaut

    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
    " Le croquemitaine ! Aaaaaah ! Où ça ? " ©Homer Simpson
      0  0

  3. #3
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro Frédéric BROUARD
    Expert SGBDR & SQL
    Inscrit en
    mai 2002
    Messages
    13 415
    Détails du profil
    Informations personnelles :
    Nom : Homme Frédéric BROUARD
    Localisation : France

    Informations professionnelles :
    Activité : Expert SGBDR & SQL
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 13 415
    Points : 27 564
    Points
    27 564

    Par défaut

    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 +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Blog SQL, SQL Server, modélisation données : http://blog.developpez.com/sqlpro
    http://www.sqlspot.com : modélisation, conseils, audit, optimisation, formation
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *
      2  0

  4. #4
    Membre extrêmement actif
    Avatar de kedare
    Profil pro Mathieu
    Administrateur systèmes et réseaux
    Inscrit en
    juillet 2005
    Messages
    1 487
    Détails du profil
    Informations personnelles :
    Nom : Mathieu
    Localisation : France

    Informations professionnelles :
    Activité : Administrateur systèmes et réseaux

    Informations forums :
    Inscription : juillet 2005
    Messages : 1 487
    Points : 1 289
    Points
    1 289

    Par défaut

    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
      1  0

  5. #5
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro Frédéric BROUARD
    Expert SGBDR & SQL
    Inscrit en
    mai 2002
    Messages
    13 415
    Détails du profil
    Informations personnelles :
    Nom : Homme Frédéric BROUARD
    Localisation : France

    Informations professionnelles :
    Activité : Expert SGBDR & SQL
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 13 415
    Points : 27 564
    Points
    27 564

    Par défaut

    Citation Envoyé par kedare Voir le message
    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 +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Blog SQL, SQL Server, modélisation données : http://blog.developpez.com/sqlpro
    http://www.sqlspot.com : modélisation, conseils, audit, optimisation, formation
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *
      0  1

  6. #6
    Membre chevronné Avatar de Oishiiii
    Administrateur de bases de données
    Inscrit en
    août 2009
    Messages
    412
    Détails du profil
    Informations personnelles :
    Âge : 26

    Informations professionnelles :
    Activité : Administrateur de bases de données

    Informations forums :
    Inscription : août 2009
    Messages : 412
    Points : 652
    Points
    652

    Par défaut

    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 :
    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..
      0  0

  7. #7
    Membre extrêmement actif
    Avatar de kedare
    Profil pro Mathieu
    Administrateur systèmes et réseaux
    Inscrit en
    juillet 2005
    Messages
    1 487
    Détails du profil
    Informations personnelles :
    Nom : Mathieu
    Localisation : France

    Informations professionnelles :
    Activité : Administrateur systèmes et réseaux

    Informations forums :
    Inscription : juillet 2005
    Messages : 1 487
    Points : 1 289
    Points
    1 289

    Par défaut

    Citation Envoyé par SQLpro Voir le message
    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...
      0  0

  8. #8
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro Frédéric BROUARD
    Expert SGBDR & SQL
    Inscrit en
    mai 2002
    Messages
    13 415
    Détails du profil
    Informations personnelles :
    Nom : Homme Frédéric BROUARD
    Localisation : France

    Informations professionnelles :
    Activité : Expert SGBDR & SQL
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 13 415
    Points : 27 564
    Points
    27 564

    Par défaut

    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 +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Blog SQL, SQL Server, modélisation données : http://blog.developpez.com/sqlpro
    http://www.sqlspot.com : modélisation, conseils, audit, optimisation, formation
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *
      1  0

  9. #9
    Nouveau Membre du Club
    Inscrit en
    mars 2008
    Messages
    52
    Détails du profil
    Informations forums :
    Inscription : mars 2008
    Messages : 52
    Points : 25
    Points
    25

    Par défaut un minimum de respect

    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.
      2  0

  10. #10
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro Frédéric BROUARD
    Expert SGBDR & SQL
    Inscrit en
    mai 2002
    Messages
    13 415
    Détails du profil
    Informations personnelles :
    Nom : Homme Frédéric BROUARD
    Localisation : France

    Informations professionnelles :
    Activité : Expert SGBDR & SQL
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 13 415
    Points : 27 564
    Points
    27 564

    Par défaut

    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 +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Blog SQL, SQL Server, modélisation données : http://blog.developpez.com/sqlpro
    http://www.sqlspot.com : modélisation, conseils, audit, optimisation, formation
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *
      0  1

  11. #11
    Invité de passage
    Inscrit en
    août 2004
    Messages
    4
    Détails du profil
    Informations forums :
    Inscription : août 2004
    Messages : 4
    Points : 1
    Points
    1

    Par défaut

    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
      0  0

  12. #12
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro Frédéric BROUARD
    Expert SGBDR & SQL
    Inscrit en
    mai 2002
    Messages
    13 415
    Détails du profil
    Informations personnelles :
    Nom : Homme Frédéric BROUARD
    Localisation : France

    Informations professionnelles :
    Activité : Expert SGBDR & SQL
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 13 415
    Points : 27 564
    Points
    27 564

    Par défaut

    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 +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Blog SQL, SQL Server, modélisation données : http://blog.developpez.com/sqlpro
    http://www.sqlspot.com : modélisation, conseils, audit, optimisation, formation
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *
      0  1

  13. #13
    Modérateur
    Avatar de CinePhil
    Homme Profil pro Philippe Leménager
    Ingénieur d'études en informatique
    Inscrit en
    août 2006
    Messages
    13 817
    Détails du profil
    Informations personnelles :
    Nom : Homme Philippe Leménager
    Âge : 51
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : août 2006
    Messages : 13 817
    Points : 23 076
    Points
    23 076

    Par défaut

    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 :
    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 :
    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.
    Philippe Leménager. Ingénieur d'étude à l'École Nationale de Formation Agronomique. Autoentrepreneur.
    Mon blog sur la conception des BDD, le langage SQL, le PHP avec Zend Framework...
    « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
    À la maison comme au bureau, j'utilise la suite Linux Mageïa !
      1  0

  14. #14
    Invité de passage
    Inscrit en
    mai 2005
    Messages
    9
    Détails du profil
    Informations forums :
    Inscription : mai 2005
    Messages : 9
    Points : 4
    Points
    4

    Par défaut

    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 !
      0  0

  15. #15
    Modérateur
    Avatar de CinePhil
    Homme Profil pro Philippe Leménager
    Ingénieur d'études en informatique
    Inscrit en
    août 2006
    Messages
    13 817
    Détails du profil
    Informations personnelles :
    Nom : Homme Philippe Leménager
    Âge : 51
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : août 2006
    Messages : 13 817
    Points : 23 076
    Points
    23 076

    Par défaut

    Regarde le point 2) de mon message juste au dessus du tien.
    Code :
    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.
    Philippe Leménager. Ingénieur d'étude à l'École Nationale de Formation Agronomique. Autoentrepreneur.
    Mon blog sur la conception des BDD, le langage SQL, le PHP avec Zend Framework...
    « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
    À la maison comme au bureau, j'utilise la suite Linux Mageïa !
      0  0

  16. #16
    Invité de passage
    Inscrit en
    mai 2005
    Messages
    9
    Détails du profil
    Informations forums :
    Inscription : mai 2005
    Messages : 9
    Points : 4
    Points
    4

    Par défaut

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

  17. #17
    Membre actif

    Profil pro
    Inscrit en
    août 2009
    Messages
    85
    Détails du profil
    Informations personnelles :
    Âge : 42
    Localisation : France, Gironde (Aquitaine)

    Informations forums :
    Inscription : août 2009
    Messages : 85
    Points : 199
    Points
    199

    Par défaut

    Citation Envoyé par SQLpro Voir le message
    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.
      0  0

  18. #18
    Membre du Club
    Inscrit en
    novembre 2006
    Messages
    174
    Détails du profil
    Informations forums :
    Inscription : novembre 2006
    Messages : 174
    Points : 43
    Points
    43

    Par défaut

    Citation Envoyé par SQLpro Voir le message
    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
      0  0

  19. #19
    Membre extrêmement actif
    Avatar de kedare
    Profil pro Mathieu
    Administrateur systèmes et réseaux
    Inscrit en
    juillet 2005
    Messages
    1 487
    Détails du profil
    Informations personnelles :
    Nom : Mathieu
    Localisation : France

    Informations professionnelles :
    Activité : Administrateur systèmes et réseaux

    Informations forums :
    Inscription : juillet 2005
    Messages : 1 487
    Points : 1 289
    Points
    1 289

    Par défaut

    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.
      0  0

  20. #20
    Modérateur
    Avatar de CinePhil
    Homme Profil pro Philippe Leménager
    Ingénieur d'études en informatique
    Inscrit en
    août 2006
    Messages
    13 817
    Détails du profil
    Informations personnelles :
    Nom : Homme Philippe Leménager
    Âge : 51
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : août 2006
    Messages : 13 817
    Points : 23 076
    Points
    23 076

    Par défaut

    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 !
    Philippe Leménager. Ingénieur d'étude à l'École Nationale de Formation Agronomique. Autoentrepreneur.
    Mon blog sur la conception des BDD, le langage SQL, le PHP avec Zend Framework...
    « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
    À la maison comme au bureau, j'utilise la suite Linux Mageïa !
      1  0

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •