web-dev-qa-db-fra.com

Schéma de nommage de clé étrangère

Je commence tout juste à travailler avec des clés étrangères pour la première fois et je me demande s’il existe un schéma de nommage standard à utiliser pour elles.

Étant donné ces tableaux:

task (id, userid, title)
note (id, taskid, userid, note);
user (id, name)

Lorsque les tâches ont des notes, les tâches appartiennent à des utilisateurs et les utilisateurs créent des notes.

Comment les trois clés étrangères seraient-elles nommées dans cette situation? Ou bien, est-ce que ça compte vraiment ?

Mise à jour : Cette question concerne les noms de clés étrangères, pas les noms de champs!

databasenaming-conventionsforeign-keys
124
nickf

La convention standard dans SQL Server est la suivante:

FK_ForeignKeyTable_PrimaryKeyTable

Ainsi, par exemple, la clé entre les notes et les tâches serait:

FK_note_task

Et la clé entre les tâches et les utilisateurs serait:

FK_task_user

Cela vous donne une vue «en un coup d'œil» des tables impliquées dans la clé, ce qui vous permet de voir facilement les tables dont dépend une (la première nommée) (la deuxième nommée). Dans ce scénario, le jeu complet de clés serait:

FK_task_user
FK_note_task
FK_note_user

Vous pouvez donc voir que les tâches dépendent des utilisateurs et que les notes dépendent à la fois des tâches et des utilisateurs.

153
Greg Beech

J'utilise deux caractères de soulignement comme délimiteur i.e. 

fk__ForeignKeyTable__PrimaryKeyTable

En effet, les noms de table contiennent parfois des caractères de soulignement. Cela suit la convention de dénomination pour les contraintes, car les noms des éléments de données contiennent souvent des caractères de soulignement, par ex. 

CREATE TABLE NaturalPersons (
   ...
   person_death_date DATETIME, 
   person_death_reason VARCHAR(30) 
      CONSTRAINT person_death_reason__not_zero_length
         CHECK (DATALENGTH(person_death_reason) > 0), 
   CONSTRAINT person_death_date__person_death_reason__interaction
      CHECK ((person_death_date IS NULL AND person_death_reason IS NULL)
              OR (person_death_date IS NOT NULL AND person_death_reason IS NOT NULL))
        ...
33
onedaywhen

Que diriez-vous de FK_TABLENAME_COLUMNNAME?

KeepItSimpleStupid lorsque cela est possible.

13
EvilTeach

D'habitude, je laisse simplement mon identifiant PK nommé, puis concatène mon nom de table et le nom de colonne de clé lorsque je nomme des FK dans d'autres tables. Je ne m'embarrasse jamais avec les chameaux, parce que certaines bases de données rejettent la distinction entre majuscules et minuscules et renvoient simplement tous les noms en minuscules ou majuscules. Dans tous les cas, voici à quoi ma version de vos tables ressemblerait:

task (id, userid, title);
note (id, taskid, userid, note);
user (id, name);

Notez que je nomme également mes tables au singulier, car une ligne représente l'un des objets que je persiste. Beaucoup de ces conventions sont une préférence personnelle. Je suggérerais qu'il est plus important de choisir une convention et de toujours l'utiliser, que d'adopter la convention de quelqu'un d'autre.

9
Steve Moyer

Une note de Microsoft concernant SQL Server:

Une contrainte FOREIGN KEY ne doit pas nécessairement être liée à un PRIMARY KEY contrainte dans une autre table; il peut également être défini pour référencer les colonnes d'une contrainte UNIQUE dans une autre table.

alors, je vais utiliser des termes décrivant la dépendance au lieu des termes conventionnels relation primaire/étrangère.

Lorsque vous référencez la PRIMARY KEY de la table independent (parent) avec la ou les colonnes portant le même nom dans la table dépendante (enfant) , j'omets le ou les noms de colonne:

FK_ChildTable_ParentTable

Lorsque vous référencez d'autres colonnes, le nom des colonnes varie d'une table à l'autre, ou simplement pour être explicite:

FK_ChildTable_childColumn_ParentTable_parentColumn
7
bvj

C'est probablement une tuerie excessive, mais cela fonctionne pour moi. Cela m’aide beaucoup lorsque j’ai particulièrement affaire aux VLDB. J'utilise les éléments suivants: 

CONSTRAINT [FK_ChildTableName_ChildColName_ParentTableName_PrimaryKeyColName]

Bien sûr, si pour une raison quelconque vous ne référencez pas une clé primaire, vous devez référencer une colonne contenue dans une contrainte unique, dans ce cas: 

CONSTRAINT [FK_ChildTableName_ChildColumnName_ParentTableName_ColumnInUniqueConstaintName]

Peut-il être long, oui. A-t-il aidé à garder les informations claires pour les rapports, ou m'a-t-il permis de sauter rapidement sur le fait que le problème potentiel se situe pendant une alerte-produit 100% aimerait connaître l'opinion des gens sur cette convention d'appellation. 

1
SSISPissesMeOff

Mon approche habituelle est

FK_ColumnNameOfForeignKey_TableNameOfReference_ColumnNameOfReference

Ou en d'autres termes

FK_ChildColumnName_ParentTableName_ParentColumnName

De cette façon, je peux nommer deux clés étrangères qui font référence à la même table, comme un history_info table avec column actionBy and actionTo à partir de users_info table

Ce sera comme

FK_actionBy_usersInfo_name - For actionBy
FK_actionTo_usersInfo_name - For actionTo

Notez que:

Je n'ai pas inclus le nom de la table enfant parce que cela me semble logique, je suis dans la table de l'enfant afin que je puisse facilement assumer le nom de la table de l'enfant. Le total de ses caractères est de 26 et correspond bien à la limite de 30 caractères d’Oracle qui a été énoncée par Charles Burns dans un commentaire ici

Note aux lecteurs: Plusieurs des meilleures pratiques répertoriées ci-dessous ne fonctionnent pas dans Oracle en raison de sa limite de 30 caractères. Un nom de table ou nom de colonne peut déjà être près de 30 caractères, donc une convention la combinaison des deux en un seul nom nécessite une norme de troncature ou autres astuces. - Charles Burns

1
Cary Bondoc

Sur la base des réponses et des commentaires, une convention de dénomination incluant la table FK, le champ FK et la table PK (FK_FKTbl_FKCol_PKTbl) devrait éviter les conflits de noms de contraintes FK.

Donc, pour les tables données ici:

fk_task_userid_user
fk_note_userid_user

Donc, si vous ajoutez une colonne pour savoir qui a modifié en dernier une tâche ou une note ...

fk_task_modifiedby_user
fk_note_modifiedby_user
0
Chad Kieffer

Essayez d’utiliser l’UUID de version 4 supérieure avec le premier octet remplacé par FK et par '_' (trait de soulignement) au lieu de '-' (tiret).

Par exemple.

  • FK_4VPO_K4S2_A6M1_RQLEYLT1VQYV
  • FK_1786_45A6_A17C_F158C0FB343E
  • FK_45A5_4CFA_84B0_E18906927B53

La justification est la suivante

  • Algorithme de génération strict => noms uniformes;
  • La longueur de la clé est inférieure à 30 caractères}, qui désigne la limitation de la longueur du nom dans Oracle (avant 12c);
  • Si votre nom d'entité change, vous vous n'avez pas besoin de renommer votre FK comme dans l'approche basée sur le nom d'entité (si DB prend en charge l'opérateur de changement de nom de table);
  • On utilisera rarement le nom de la contrainte de clé étrangère. Par exemple. L'outil de base de données montre généralement à quoi la contrainte s'applique. Pas besoin d'avoir peur du look cryptique, car vous pouvez éviter de l'utiliser pour le "décryptage".
0
coldserenity