Convention de nommage des clés étrangères

Question

Lors de la création de relations entre les tables (dans mysql), j'ai rencontré un dilemme de nommage.

Par exemple, si je créais un site où un projet pouvait être créé par plusieurs utilisateurs et lu par plusieurs utilisateurs, pour relier des tables de questions et d'utilisateur, j'aurais potentiellement besoin de deux tables.

**auteurs_de_projet**
questionId
userId

et

**soumissionnaires_de_projet**
questionId
userId

Le problème ici est que les deux tables se ressemblent, à l'exception du nom de la table. Une représentation plus utile serait probablement

auteurs_de_projet
questionId
authorId

et

soumissionnaires_de_projet
questionId
bidderID

Le problème ici est maintenant que authorId et readerId ne sont en fait que des userIds, et le nom ne reflète pas cela, ce qui pourrait potentiellement indiquer de manière trompeuse que authorId et bidderId sont uniques et différents en soi.

Je suis sûr que mon exemple aura de nombreuses lacunes, mais j'ai rencontré ce problème assez récemment, donc ma question est : quelle méthode utilisez-vous ?

Answer 1

Qu'est-ce qui ne va pas avec author_userID et bidder_userID?

Vous avez des personnes qui jouent des rôles, ce qui est toujours une conception difficile. Vous devez refléter le rôle ainsi que l'objet sous-jacent jouant ce rôle.

Answer 2

Je dirais:

project\_users
-------------
questionId
userId
roleId

où roleId est lié à une table qui différencie entre un auteur, un enchérisseur, etc. Effet positif - vous pouvez contrôler avec le choix de la clé primaire composite si un utilisateur peut être seulement un (auteur ou enchérisseur) ou les deux. Le premier signifierait une clé sur questionId, userId, le second une clé sur les trois champs.

Note latérale: Personnellement, je préfère rester dans un seul schéma de nommage. Soit j'utilise everyhing_with_underscores, soit j'utilise camelCase/PascalCase, mais pas project_users et userId dans la même base de données.

Answer 3

Lorsque je le peux, j'utilise le nom exact du champ PK auquel je fais référence. Cependant, il peut arriver que j'aie besoin de deux références au même identifiant dans la même table, dans ce cas je ferais :

Utilisateurs IDUtilisateur

Commandes Customer_IDUtilisateur SalesRep_IDUtilisateur

De cette manière, vous connaissez l'utilisation spécifique de l'identifiant ainsi que le nom réel de l'identifiant.

Answer 4

Je préfère garder le nom de la clé étrangère identique au nom de la clé primaire lorsque c'est possible. Cela vous aide à déterminer rapidement si une colonne est une clé étrangère vers une autre table et il n'y a aucune ambiguïté quant à la table à laquelle elle fait référence.

tblUser

• UserID (pk)

tblProjectAuthor

• ProjectAuthorID (pk)
• UserID (fk vers tblUser)

tblProjectBidder

• ProjectBidderID (pk)
• UserID (fk vers tblUser)

Dans vos requêtes, vous pouvez utiliser des préfixes pour différencier de quelle table vient le UserID que vous référencez.

sélectionner author.UserID 
de tblProjectAuthor author 
left join tblUser user on user.UserID = author.UserID

Le seul problème que nous avons rencontré avec ce schéma de nommage est lorsque vous référencez une clé étrangère plusieurs fois dans la même table. Un bon exemple serait une table de jointure de soi-même. Dans ces cas, ma seule suggestion est de préfixer avec un mot ou une phrase significative qui aide à distinguer tout en vous permettant de reconnaître que la colonne est une clé étrangère.

Par exemple :

tblEmployee

• EmployeeID (pk)
• ManagerEmployeeID (fk vers tblEmployee)

Answer 5

Si vous posez simplement des questions sur le nommage, je choisirais le schéma de nommage qui offre le plus de documentation intrinsèquement. Personnellement, je pense que ce serait la première option. Cependant, tant que vous vous assurez que ce que vous décidez est cohérent et documenté d'une manière ou d'une autre, je pense que les deux fonctionneront bien.

Cependant, avez-vous pensé à ajouter plus de tables? Peut-être avoir une table utilisateurs, qui stocke les identifiants et d'autres informations sur les utilisateurs, une table projets qui stocke des projets, une table soumissionnaires qui fait correspondre les utilisateurs qui soumissionnent pour des projets, et une table auteurs qui fait correspondre les utilisateurs aux projets qu'ils ont écrits?