IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

MySQL Discussion :

Convention Nommage de tables bdd


Sujet :

MySQL

  1. #1
    Membre chevronné

    Homme Profil pro
    développeur
    Inscrit en
    octobre 2013
    Messages
    1 508
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Oise (Picardie)

    Informations professionnelles :
    Activité : développeur

    Informations forums :
    Inscription : octobre 2013
    Messages : 1 508
    Points : 1 930
    Points
    1 930
    Par défaut Convention Nommage de tables bdd
    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

  2. #2
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    mai 2002
    Messages
    20 481
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 20 481
    Points : 48 362
    Points
    48 362
    Par défaut
    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 +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  3. #3
    Modérateur

    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    août 2006
    Messages
    16 581
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 57
    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 : 16 581
    Points : 33 411
    Points
    33 411
    Billets dans le blog
    13
    Par défaut
    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.
    Philippe Leménager. Ingénieur d'étude à l'École Nationale Supérieure de Formation de l'Enseignement Agricole. Autoentrepreneur.
    Mon ancien blog sur la conception des BDD, le langage SQL, le PHP... et mon nouveau blog sur les mêmes sujets.
    « 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 !

  4. #4
    Expert éminent sénior Avatar de Artemus24
    Homme Profil pro
    Agent secret au service du président Ulysses S. Grant !
    Inscrit en
    février 2011
    Messages
    4 755
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Agent secret au service du président Ulysses S. Grant !
    Secteur : Finance

    Informations forums :
    Inscription : février 2011
    Messages : 4 755
    Points : 13 644
    Points
    13 644
    Par défaut
    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.

    @+
    Si vous êtes de mon aide, vous pouvez cliquer sur .
    Mon site : http://www.jcz.fr

  5. #5
    Expert éminent sénior
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    6 539
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 6 539
    Points : 20 239
    Points
    20 239
    Billets dans le blog
    2
    Par défaut
    @Artemus24 d'accord avec quelques détails supplémentaires en rouge dans le texte :

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

  6. #6
    Modérateur

    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    août 2006
    Messages
    16 581
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 57
    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 : 16 581
    Points : 33 411
    Points
    33 411
    Billets dans le blog
    13
    Par défaut
    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.
    Philippe Leménager. Ingénieur d'étude à l'École Nationale Supérieure de Formation de l'Enseignement Agricole. Autoentrepreneur.
    Mon ancien blog sur la conception des BDD, le langage SQL, le PHP... et mon nouveau blog sur les mêmes sujets.
    « 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 !

  7. #7
    Expert éminent sénior
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    6 539
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 6 539
    Points : 20 239
    Points
    20 239
    Billets dans le blog
    2
    Par défaut
    Citation Envoyé par CinePhil Voir le message
    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

  8. #8
    Expert éminent sénior Avatar de Artemus24
    Homme Profil pro
    Agent secret au service du président Ulysses S. Grant !
    Inscrit en
    février 2011
    Messages
    4 755
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Agent secret au service du président Ulysses S. Grant !
    Secteur : Finance

    Informations forums :
    Inscription : février 2011
    Messages : 4 755
    Points : 13 644
    Points
    13 644
    Par défaut
    Salut à tous.

    Citation Envoyé par Escartefigue
    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é.

    Citation Envoyé par Escartefigue
    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.

    Citation Envoyé par Escartefigue
    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.

    Citation Envoyé par Escartefigue
    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.

    @+
    Si vous êtes de mon aide, vous pouvez cliquer sur .
    Mon site : http://www.jcz.fr

  9. #9
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    mai 2002
    Messages
    20 481
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 20 481
    Points : 48 362
    Points
    48 362
    Par défaut
    Citation Envoyé par CinePhil Voir le message
    ....
    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 +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  10. #10
    Modérateur

    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    août 2006
    Messages
    16 581
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 57
    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 : 16 581
    Points : 33 411
    Points
    33 411
    Billets dans le blog
    13
    Par défaut
    Citation Envoyé par SQLpro Voir le message
    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.
    Philippe Leménager. Ingénieur d'étude à l'École Nationale Supérieure de Formation de l'Enseignement Agricole. Autoentrepreneur.
    Mon ancien blog sur la conception des BDD, le langage SQL, le PHP... et mon nouveau blog sur les mêmes sujets.
    « 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 !

  11. #11
    Membre éprouvé
    Homme Profil pro
    Développeur Oracle
    Inscrit en
    décembre 2019
    Messages
    633
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Développeur Oracle

    Informations forums :
    Inscription : décembre 2019
    Messages : 633
    Points : 1 019
    Points
    1 019
    Par défaut
    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.

  12. #12
    Membre averti
    Profil pro
    Administrateur
    Inscrit en
    mai 2008
    Messages
    195
    Détails du profil
    Informations personnelles :
    Localisation : Canada

    Informations professionnelles :
    Activité : Administrateur
    Secteur : Industrie

    Informations forums :
    Inscription : mai 2008
    Messages : 195
    Points : 369
    Points
    369
    Par défaut
    Citation Envoyé par kevin254kl Voir le message
    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 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

  13. #13
    Expert éminent sénior Avatar de Artemus24
    Homme Profil pro
    Agent secret au service du président Ulysses S. Grant !
    Inscrit en
    février 2011
    Messages
    4 755
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Agent secret au service du président Ulysses S. Grant !
    Secteur : Finance

    Informations forums :
    Inscription : février 2011
    Messages : 4 755
    Points : 13 644
    Points
    13 644
    Par défaut
    Salut Manzeki

    Citation Envoyé par 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 ?

    Citation Envoyé par Manzeki
    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.

    Citation Envoyé par Manzeki
    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.

    @+
    Si vous êtes de mon aide, vous pouvez cliquer sur .
    Mon site : http://www.jcz.fr

  14. #14
    Expert éminent sénior
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    6 539
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 6 539
    Points : 20 239
    Points
    20 239
    Billets dans le blog
    2
    Par défaut
    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.

Discussions similaires

  1. [AC-2003] Créer et lier nouvelles tables - BDD fractionnée
    Par Poisell dans le forum Modélisation
    Réponses: 2
    Dernier message: 15/04/2009, 19h14
  2. Copier une table BdD A vers une base de données
    Par Ste20 dans le forum MS SQL Server
    Réponses: 3
    Dernier message: 07/10/2007, 21h12
  3. Obtenir champ d'une table BDD Access
    Par hari37 dans le forum Windows Forms
    Réponses: 4
    Dernier message: 04/07/2007, 15h22
  4. Incrementation table bdd incomplète
    Par inforlab dans le forum Accès aux données
    Réponses: 4
    Dernier message: 21/05/2007, 22h57
  5. La fin de ma Table BDD ?
    Par devlopassion dans le forum C++Builder
    Réponses: 3
    Dernier message: 13/09/2006, 18h44

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo