Quelle est la convention de dénomination appropriée pour les FK MySQL?


Réponses:


142

Dans MySQL, il n'est pas nécessaire de donner un nom symbolique aux contraintes de clé étrangère. Si aucun nom n'est donné, InnoDB crée automatiquement un nom unique.

Dans tous les cas, c'est la convention que j'utilise:

fk_[referencing table name]_[referenced table name]_[referencing field name]

Exemple:

CREATE TABLE users(
    user_id    int,
    name       varchar(100)
);

CREATE TABLE messages(
    message_id int,
    user_id    int
);

ALTER TABLE messages ADD CONSTRAINT fk_messages_users_user_id 
    FOREIGN KEY (user_id) REFERENCES users(user_id);

J'essaie de m'en tenir aux mêmes noms de champ dans le référencement et les tables référencées, comme user_iddans l'exemple ci-dessus. Lorsque ce n'est pas pratique, j'ajoute également le nom du champ référencé au nom de la clé étrangère.

Cette convention de dénomination me permet de "deviner" le nom symbolique simplement en regardant les définitions de table, et en plus elle garantit également des noms uniques.


13
La raison de la création d'un nom symbolique est de faire référence lorsque vous voulez / devez supprimer la contrainte. Oracle et SQL Server vous permettent de désactiver des contraintes spécifiques. Si vous n'avez pas fk dans le nom, vous devez confirmer que la contrainte est une contrainte de clé étrangère ...
OMG Ponies

11
Ce que j'aime faire, c'est utiliser un double trait de soulignement entre le nom de la table de référence et le nom de la table référencée. Cela vous donne le double avantage des listes alphabétiques regroupant tous les FK d'une table et en même temps vous aidant à éviter les collisions / confusion de noms lorsqu'il y a plusieurs noms de tables de mots. J'omets également la partie champ du nom quand il est trivial (c'est-à-dire qu'un seul champ int fait référence à l'identité PK d'une autre table).
Joel Brown du

2
Et s'il y a plus d'une clé étrangère? Exemple: member_id~> lien vers le membre de la table, edited_id~> clé étrangère pour l'utilisateur édité, également lien vers le membre de la table. Comment dois-je les nommer?
TomSawyer

@TomSawyer: J'ajoute «pk_» à toutes les clés étrangères, suivi de la table référencée (par exemple «membres»), suivi de l'usage / sens (par exemple «éditeur» ou «auteur»). J'ai donc quelque chose comme «pk_members_author» ou «pk_members_editor».
Nrgyzer

28

mon choix est différent. à mon avis, une table devrait avoir un idchamp, pas un user_idseul, car la table est simplement appelée user, donc:

CREATE TABLE users(
   id    int,
   name       varchar(100)
);

CREATE TABLE messages(
   id int,
   user_id    int
);

user_idin messagestable est un champ fk donc il doit indiquer clairement quel id est ( user_id).

une convention de dénomination pleinement explicite, à mon avis, pourrait être:

fk_[referencing table name]_[referencing field name]_[referenced table name]_[referenced field name]

i.e.: `fk_messages_user_id_users_id`

Remarque:

  • vous pouvez, dans certains cas, omettre le deuxième élément ([nom du champ de référence])
  • ce fk pourrait être unique, car si une messages_usertable existe, le nom du champ de référence devrait être user_id(et pas seulement id) et le nom fk devrait être:

    fk_messages_user_user_id_users_id

en d'autres termes, une convention de dénomination de clé étrangère vous garantit des noms uniques si vous utilisez également une convention de dénomination «champ référencé / référencé» (et vous pouvez choisir la vôtre, bien sûr).


4
Les noms ont un moyen de persister dans le code. Finalement, vous trouverez une $idvariable quelque part sans aucune idée de la table à laquelle elle appartient. Plus votre base de code est ancienne et plus les gens ont travaillé dessus, plus cela devient probable.
CJ Dennis

9

Si vous ne vous retrouvez pas à référencer les fk aussi souvent après leur création, une option est de rester simple et de laisser MySQL faire le nommage pour vous (comme Daniel Vassallo le mentionne au début de sa réponse ).

Bien que vous ne puissiez pas "deviner" de manière unique les noms des contraintes avec cette méthode, vous pouvez facilement trouver le nom de la contrainte de clé étrangère en exécutant une requête:

use information_schema;
select TABLE_NAME,COLUMN_NAME,CONSTRAINT_NAME, REFERENCED_TABLE_NAME,REFERENCED_COLUMN_NAME from KEY_COLUMN_USAGE where REFERENCED_TABLE_SCHEMA = 'your_db_schema_name' ORDER BY TABLE_NAME;

Par exemple, vous pouvez recevoir les éléments suivants de la requête:

+------------+-------------+-----------------+-----------------------+------------------------+
| TABLE_NAME | COLUMN_NAME | CONSTRAINT_NAME | REFERENCED_TABLE_NAME | REFERENCED_COLUMN_NAME |
+------------+-------------+-----------------+-----------------------+------------------------+
| note       | taskid      | note_ibfk_2     | task                  | id                     |
| note       | userid      | note_ibfk_1     | user                  | id                     |
| task       | userid      | task_ibfk_1     | user                  | id                     |
+------------+-------------+-----------------+-----------------------+------------------------+

Si cette étape supplémentaire n'est pas trop pour vous, vous devriez pouvoir trouver facilement le fk que vous recherchez.


1
fk-[referencing_table]-[referencing_field]

La raison est la combinaison de referencing_tableet referencing_fieldest unique dans une base de données. De cette façon, le nom de la clé étrangère est facile à lire, par exemple:

table `user`:
    id
    name
    role

table `article`:
    id
    content
    created_user_id /* --> user.id */
    reviewed_user_id /* --> user.id */

Nous avons donc deux clés étrangères:

fk-article-created_user_id
fk-article-reviewed_user_id

L'ajout d'un usernom de table au nom de clé étrangère est redondant.


Et si le nom de la base de données est user_role? useret roleont une relation manytomany et user_roleest la table qui contient toute la clé étrangère. Doit-il l'être fk_user_role_role?
Nguyễn Đức Tâm

@ NguyễnĐứcTâm fk-user_role-role
Văn Quyết
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.