Discussion :

[Shinja]

Salut, je suis devant un sacré dilemme à savoir : quelle est la meilleure façon de nommer les tables dans une base de données SQL ? J'ai lu pas mal de documentation à ce sujet, mais rien concernant les noms de tables composés. Du coup je ne sais pas si c'est une bonne pratique de commencer le nom d'une table par ce qu'elle regroupe. Par exemple pour la table "article", j'ai nommer les autres tables de cette façon : "article_comments", "article_sources", "article_evaluations" ou bien "user_profiles" plutôt que "profiles". Cela me permet de bien regrouper les tables, mais j'ai lu qu'il fallait utiliser un seul lorsque cela est possible, alors je me demandais qu'elle était la meilleure façon de faire. Merci d'avance pour les réponses !

[Artemus24]

Salut Shinja.

quelle est la meilleure façon de nommer les tables dans une base de données SQL ?

Il n'y a pas de règles officielles pour nommer quoi que ce soit dans une base de données.

En ce qui me concerne les noms de colonnes, j'aime bien utiliser un code sur trois caractères. Par exemple : code article du client devient "codartcli".
Si tu n'utilises pas des noms composés, mets tout simplement le nom en entier, à la condition qu'il soit compréhensible.
Exemple : 'libelle', 'sexe', 'matricule'.

On établie un dictionnaire de données qui définie le rôle que doit jouer chaque attribue dans le MCD.
La règle est l'unicité du nom dans la base. Ainsi 'codartcli' aura la même signification partout dans la base.

Je préfixe un nom de colonne quand je fais une distinction entre une table 't_' et une view 'v_'.

Par exemple pour la table "article", j'ai nommer les autres tables de cette façon : "article_comments", "article_sources", "article_evaluations"

Pour le nom des tables, je n'aime pas les noms trop longs. Le nom 'comment', 'source' et 'évaluation' me convient parfaitement. Inutile de les mettre au pluriel.
Si tu as besoin de les préfixer pour les distinguer d'un autre groupe de table, ce que tu fais est correcte.

--> http://sqlpro.developpez.com/cours/standards/
--> http://www.sqlspot.com/Norme-de-developpement.html
--> http://blog.developpez.com/sqlpro/p7...ention_help_to

@+

[escartefigue]

Bonjour,

La question concerne vraisemblablement une base à usage privé, car dans le monde des entreprises, il y a souvent une codification imposée

Dans les deux cas, il faut éviter
- les noms réservés SQL : on ne nommera pas une table "select", "table", "column" etc...
- les caractères diacritiques ni ligatures : pas d'accent, cédille, e dans l'o etc...
- pas de blanc

Personnellement, tout comme Artemus24, j'aime respecter une codif courte, les noms d'objets à rallonge sont peu pratiques à l'usage

[SQLpro]

Salut Shinja.

Il n'y a pas de règles officielles pour nommer quoi que ce soit dans une base de données.

Si, la norme SQL....

1) n'utiliser que les 26 lettres de l'alphabet latin (A à Z), sans diacritique et en majuscule + les 10 chiffres (0 à 1) + le blanc souligné (ou "underscore")
2) ne pas dépasser 128 caractères
3) évitez d'utiliser un mot réservé du SQL comme TYPE, DATE, USER... (voir liste)
4) si l'on désire utiliser un mot réservé du SQL, alors l'entourere de guillemets simples. Exemple : CREATE TABLE "SELECT" ("DATE" DATE, "TYPE" CHAR(4));

A +

[Shinja]

Merci pour vos réponses. Pour le moment j'ai opté pour des noms simples sans rallonge, car c'est pas forcément évident de travailler surtout avec CakePHP lors des relations belongsToMany. Par exemple si j'ai une table "articles", "article_categories" et que je fais une relations belongsToMany, le framework s'attend à avoir une table de type articles_article_categories. Ça fait un peu long non ?

[Artemus24]

Salut à tous.

@ SQLPRO : je suis d'accord avec toi, mais je ne parlais pas des normes SQL
Mais bien de la façon de nommer les trigger, procédures stockées, tables et autres colonnes dans une base.

Dans de vieilles bases (en DL1, si j'ai un bon souvenir), j'ai connu des noms de tables, genre "T0925".
Pire, je crois que l'on était limité en nombre de caractères.
Franchement, c'est pas du tout parlant et l'on peut vite se tromper lorsque l'on manipule ce genre de nom.

Ou encore des noms en rallonge avec parfois un seul caractère qui fait la différence.

le framework s'attend à avoir une table de type articles_article_categories. Ça fait un peu long non ?

D'où l'intérêt de faire court !

@+

[escartefigue]

Dans de vieilles bases (en DL1, si j'ai un bon souvenir), j'ai connu des noms de tables, genre "T0925".
Pire, je crois que l'on était limité en nombre de caractères.
Franchement, c'est pas du tout parlant et l'on peut vite se tromper lorsque l'on manipule ce genre de nom.

La on est un peu en marge du sujet car DL1 c'est du mainframe, ce n'était pas une base relationnelle, et surtout, ne connaissait pas de tables, mais des "segments"

Pour rester dans le monde Mainframe, sur les sites DB2 for Z/OS, tout comme les sites DL1 on utilise le plus souvent (pour des raisons historiques et culturelles) des noms sur 8 caractères seulement, alors que techniquement, on peut créer des tables avec des noms jusqu'à 128 caractères depuis bien longtemps.

Ceci dit, et pour en revenir au sujet, quand la codification est normée de façon intelligente, et c'est souvent le cas dans les grosses boites qui utilisent le mainframe, les 8 caractères permettent d'identifier très facilement le contenu fonctionnel de la table (les codes utilisés faisant référence à la carto applicative, elle même normée et documentée)

J'ai travaillé il y a quelques années sur un site qui mettait en place de nouvelles bases de données dans le cadre d'une refonte complète du S.I.
Sur ce site, avec plusieurs milliers de tables à la clef, toutes codées sur 8 caractères, il était très facile d'identifier le contenu des tables et vues, rien que grâce à leur nom

[Artemus24]

Salut Escartefigue.

Le titre de ce sujet est :

Code :

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

Quelle est la meilleure façon de nommer les tables ?

On ne parle pas ici du type de SGBD (relationnel, réseau, hiérarchique, déductif et objet).
Mais de la façon de nommer les composants dans ces bases de données.
Il y a parfois des contraintes dites historiques comme tu le soulignes, mais c'est pas cela le problème (encore que).

L'origine de cette nomenclature commence dès le modèle conceptuel des données.
Entre autre avec le dictionnaire des données. Si dès le départ, on fait un mauvais choix alors on va se balader avec des contraintes inutiles.

Tu as un exemple donné par "Shinja" où il hiérarchise les noms. Par exemple : "articles_article_categories".
Si la table catégorie est unique dans la base de données, il est inutile de la préfixer.

Le mieux, quand c'est possible, est d'utiliser des noms courts (un simple mot), facile à retenir, porteuse d'une signification et surtout unique dans la base de données.
La table "T0925" ne veut rien dire. Mais la table "client" est parlante.
C'est tout ce que je préconise, même si mes exemples t'ont déplu.

@+

[escartefigue]

Je soulignais seulement que "T0925" n'est pas forcément moins parlant que "client" et que la notion de table n'existait pas avec DL1
Mais ce n'est pas le sujet

Je m'explique :
Si T0995 correspond à une nomenclature établie dans l'entreprise c'est probablement beaucoup plus précis que client, qui peut recouvrir :
- client comptable
- client contentieux
- client commercial
- client de livraison
- client prospect
- client de regroupement statistique
etc...

Si toute ou partie de ces entités-type existent dans l'entreprise alors il faut des noms à rallonge, dans mon exemple ci-dessus on a "client_hierarchique_segmentation_statistique" par exemple car "client" seul ne veut rien dire.
En ce cas je préfère une nomenclature, peut être pas aussi abstraite que T0995 mais une nomenclature concise et facile à comprendre

Exemple de nomenclature simple
- 1er caractère : T ou V pour table ou vue
- 2ème carac : code brique (au sens urbanisme applicatif)
- 3ème carac : code quartier de la brique (urbanisme)
- 4 à 8ème : code entité référencé dans un dictionnaire des entités
J'ai pratiqué cette codif dans une grosse boite, je n'en étais pas l'auteur, mais j'y ai très vite adhéré, comme tous les dba, développeurs et autres intervenants concernés
Les codes sont communs avec ceux des traitements et programmes, tout le monde s'y retrouve très vite et c'est beaucoup plus pratique à manipuler que des successions de mot avec underscore

Voila, c'est clair, concis et mnémotechnique.

[SQLpro]

Salut à tous.

@ SQLPRO : je suis d'accord avec toi, mais je ne parlais pas des normes SQL
Mais bien de la façon de nommer les trigger, procédures stockées, tables et autres colonnes dans une base.

Dans de vieilles bases (en DL1, si j'ai un bon souvenir), j'ai connu des noms de tables, genre "T0925".
Pire, je crois que l'on était limité en nombre de caractères.

C'est toujours le cas dans Oracle (20 car je crois), même si aujourd'hui ils travaillent à rallonger cela et se conformer à la norme SQL (128 caractères) et apparemment c'est pas gagné !
C'est d'ailleurs pour pallier à cet inconvénient qu'Oracle à inventé la notion de synonyme qui n'existe pas dans la norme (inutile).

Franchement, c'est pas du tout parlant et l'on peut vite se tromper lorsque l'on manipule ce genre de nom.

Ou encore des noms en rallonge avec parfois un seul caractère qui fait la différence.


D'où l'intérêt de faire court !

@+

Il est aussi recommandé de jouer avec les schémas SQL, mais hélas MySQmerde n'implémente pas les schémas SQL au contraire de tous les autres "bons" SGBDR.
Les schémas SQL étant des "conteneurs" d'objet, il est alors facile de créer différents schémas comme VENTE, COMPTA, MARKETING... et d'y place table, vues et procédures dedans !

A +

[skuatamad]

Le maximum de caractère sur Oracle pour tous les objets est de 30 caractères.
https://docs.oracle.com/cd/B19306_01...008.htm#i27570

Le synonyme n'a rien à voir avec la taille des noms d'objets (étant soumis aux mêmes règles) mais permet d'éviter de taper le nom du schéma propriétaire par exemple...
Bon en gros c'est pas vraiment indispensable...