Discussion :

[gadsweb]

Bonjour,

Je m'intéresse de près aux conventions de nommage des tables sql.
Pourriez-vous me dire quelle est la différence entre une table fonctionnelle et une table de référence?
Merci d'avance

[gadsweb]

Re-bonjour,

J'ai 3 tables.
1/ Table qui contient des profils (T_PROFILES) avec comme champs PRO_ID et PRO_LAB
2/ Table qui contient des droits (T_RIGHTS) avec comme champs RIG_ID et RIG_LAB
3/ Ma table de jointure (TJ_RIGHTS_PROFILES) qui évidemment attribue des droits à un profil

Ma question concerne donc le nommage des colonnes de cette table de jointure. J'ai lu des trucs un peu partout mais j’hésite et j'aimerais votre avis.
La solution envisagée consisterait à utiliser les mêmes noms de colonne dans la table de jointure que dans la table de données. Ex : PRO_ID et RIG_ID
Ce qui m'embête là-dedans c'est que du coup je perds l'info de la table qui contient ce champ et je me retrouve avec 2 colonnes dans 2 tables différentes avec le même nom.
Est-ce un soucis ? Au cas où je précise que c'est pour manipuler en C#.

Merci

[SQLpro]

Il existe une norme AFNOR en informatique précisant comment doit être identifier une information dans le SI. (je ne me rapalle hélas plus de la référence !). Elle dit ceci :
"dans le SI une même information doit être identifié de manière unique"
Ceci veut donc dire que toutes les colonnes dans une même base doivent avoir des noms différents tant qu'elle représente des informations différentes.
Et le corolaire est que "si c'est la même information, ce doit être le même nom".
Or comme une clef étrangère contient la même information que la clef primaire ou unique auquel elle fait référence, alors ce nom doit être le même.

La norme ISO SQL, renforce d'ailleurs cette idée avec la jointure naturelle (pour moi elle ne devrait JAMAIS être utilisée... amis bon). Par exemple dans votre cas :

Code :

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

1
2
3
4
SELECT *
FROM   TJ_RIGHTS_PROFILES
          NATURAL JOIN T_PROFILES
          NATURAL JOIN T_RIGHTS

Est une requête parfaitement valable sur tous les SGBDR acceptant la jointure naturelle !

A +

[gadsweb]

Merci beaucoup pour cette info claire et précise.
Effectivement je n'utilise jamais la jointure naturelle, je n'aime pas.

Je profite d'avoir affaire à un pro pour une autre question si je peux me permettre.
En plus du profil, je vais avoir d'autres tables de référence comme par exemple une table TR_SITES.

Actuellement, j'ai donc une table USERS (je ne sais pas comment définir le type, fonctionnelle, de référence ou de jointure) qui contient par exemple les champs suivants :
USE_ID, USE_NAME et donc les champs qui proviennent des tables de référence comme par exemple PRO_ID et SIT_ID.

Est-ce la bonne pratique ou alors dois-je créer une table avec juste les champs USE_ID et USE_NAME et une autre de jointure qui reprendrait USE_ID et donc les autres PRO_ID et SIT_ID ?

J'espère que c'est clair :-)

Merci de votre patience.

[SQLpro]

Tout cela doit être abordé au niveau du MCD, pas du MPD. C'est dans le MPD que vous définissez la sémantique des liens d'association et de cette sémantique va découler les cardinalités qui vont imposer telle ou telle forme physique de vos tables pour assurer l'articulation des tables entre-elles qui vont se traduire en SQL par des jointures.

Pour en revenir à votre post initial, Si vous aviez utiliser un outils de conception de BD permettant de faire un MCD et de passer au MPD, les noms auraient été conformes à ce que nous avons discuté.

Autrement dit et pour en revenir à votre 2e problème vous n'avez pas le choix ! Mais les informations que vous nous avez données sont incomplètes pour trancher !

A +

[gadsweb]

Ah mais rien n'est fait encore :-), je me renseigne justement.
Je peux donc faire une table avec juste les USERS et une table de jonction pour leur attribuer un profil et un site ou faire en une seule table, sachant que chaque utilisateur est unique et qu'il ne peut avoir qu'un seul profil et un seul site.
Pour ma part et pour une question de facilité, je n'en ferais qu'une mais je ne sais pas si c'est "good practice".
Merci

[StringBuilder]

Bonjour,

Personnellement, je ne suis absolument pas fan de la notation hongroise, que vous semblez avoir choisi pour déterminer les noms des tables.

Que la table soit une table "fonctionnelle", de "jointure" ou de "je ne sais quoi", à la limite, OSEF, d'autant plus pour la différentiation de nommage entre vues et tables.
Ceci dans une optique de simplification de la compréhension du code, mais aussi de sa maintenabilité.

Par exemple, on peut imaginer une table "tiers". Qui va contenir des client et des fournisseurs.
On peut parfaitement imaginer alors une vue "client" et une vue "fournisseur" basées sur la table "tiers" ne sélectionnant que le sous-ensemble désiré.
=> A ce moment, quelle est l'utilité, dans le code, de savoir s'il s'agit d'une vue ou d'une table ? N'importe quel SGBD sait faire des mises à jour sur les vues donc d'un point de vue sémantique, la couche de haut niveau n'a que faire de savoir si c'est une vue ou une table. Préfixer le nom de l'objet par son type est donc source de confusion, complexité et d'erreur : que se passe-t-il si demain j'ai une table "t_client" et une vue "v_client" ? Je prends laquelle ? Qui contient quoi ? WTF ?
Mais aussi ne pas oublier que demain, un DBA peut se pointer et crier à l'hérésie, et demander à remplacer les vue "client" et "fournisseur" par deux tables physiques, et abandonner la table initiale "tiers". A ce moment, si c'est préfixé dans tous les sens, vous n'avez plus qu'à passer en revue l'intégralité du code. Sans préfixes, vous n'avez qu'à vérifier que le code ne référence plus la table "tiers". Pas vraiment la même charge de boulot !

Sinon, les trigrammes, pas fan non plus.

"USE_ID", pour moi, c'est le verbe "to use", utiliser, et non "USER". Sémantiquement, je ne comprends plus rien au code.

Si vous voulez faire des abbréviations, choisissez plutôt (je ne sais plus comment ça s'appelle) qui consite à supprimer toutes les voyelle du mot (sauf si elle est en première position).

Ainsi, USER devient USR, ce que n'importe qui comprends. Et "LAB", pour vous "LABEL", chez moi "LABORATORY". Une fois de plus "LBL" est sans appel, on comprends ce que ça veut dire, si vous n'avez pas le courrage d'utiliser "LABEL" en entier.

Sinon, en règle générale, je privilégie des noms courts pour les tables, et je l'utilise comme préfixe à l'ensemble des colonnes de la table (sauf pour les clés étrangères).
Et dans les vues, pareil : renommage des colonnes avec pour préfixe le nom de la vue (cf. mon exemple avec TIERS qui devient CLIENT et FOURNISSEUR : si on n'a pas renommé les colonnes dans la vue, alors ne respecte plus la norme AFNOR citée par SQLpro).

[SQLpro]

Bonjour,

Personnellement, je ne suis absolument pas fan de la notation hongroise, que vous semblez avoir choisi pour déterminer les noms des tables.

Je n'ai pas le temps de dire tout, mais vous vous trompez lourdement l'intérêt est GIGANTESQUE !!!
je l'ai démontré à joe celko dans un congrès un jour par a + b l'inaptitude de cette façon de nommer à l'aveugle sans savoir quoi est quoi par le simple nom !!!

A +