Convention de dénomination de la clé primaire / clé étrangère [fermé]

Dans notre groupe de développement, nous avons un débat acharné concernant la convention de dénomination des clés primaires et étrangères. Il y a essentiellement deux écoles de pensée dans notre groupe:

1:

Primary Table (Employee)   
Primary Key is called ID

Foreign table (Event)  
Foreign key is called EmployeeID

ou

2:

Primary Table (Employee)  
Primary Key is called EmployeeID

Foreign table (Event)  
Foreign key is called EmployeeID

Je préfère ne pas dupliquer le nom de la table dans aucune des colonnes (donc je préfère l'option 1 ci-dessus). Conceptuellement, il est cohérent avec de nombreuses pratiques recommandées dans d'autres langues, où vous n'utilisez pas le nom de l'objet dans ses noms de propriété. Je pense que nommer la clé étrangère EmployeeID(ou Employee_IDpourrait être mieux) indique au lecteur que c'est la IDcolonne de la Employeetable.

D'autres préfèrent l'option 2 où vous nommez la clé primaire avec le préfixe du nom de la table afin que le nom de la colonne soit le même dans toute la base de données. Je vois ce point, mais vous ne pouvez plus distinguer visuellement une clé primaire d'une clé étrangère.

De plus, je pense qu'il est redondant d'avoir le nom de la table dans le nom de la colonne, car si vous considérez la table comme une entité et une colonne comme une propriété ou un attribut de cette entité, vous la considérez comme l'attribut ID du Employee, pas l' EmployeeIDattribut d'un employé. Je ne vais pas demander à mon collègue ce qu'il estPersonAge ou PersonGenderest. Je lui demande quel est son âge.

Donc, comme je l'ai dit, c'est un débat qui fait rage et nous continuons encore et encore à ce sujet. Je suis intéressé à avoir de nouvelles perspectives.

Cela n'a pas vraiment d'importance. Je n'ai jamais rencontré un système où il y a une réelle différence entre le choix 1 et le choix 2.

Jeff Atwood a publié un excellent article il y a quelque temps sur ce sujet. Fondamentalement, les gens débattent et argumentent le plus furieusement sur les sujets sur lesquels on ne peut pas prouver qu'ils ont tort. Ou sous un angle différent, ces sujets qui ne peuvent être gagnés que par le biais d'arguments du dernier homme debout.

Choisissez-en un et dites-leur de se concentrer sur les problèmes qui ont réellement un impact sur votre code.

EDIT: Si vous voulez vous amuser, demandez-leur de spécifier longuement pourquoi leur méthode est supérieure pour les références de table récursives.

Si les deux colonnes ont le même nom dans les deux tables (convention n ° 2), vous pouvez utiliser la syntaxe USING dans SQL pour enregistrer un peu de frappe et un peu de bruit standard:

SELECT name, address, amount
  FROM employees JOIN payroll USING (employee_id)

Un autre argument en faveur de la convention n ° 2 est que c'est la façon dont le modèle relationnel a été conçu.

La signification de chaque colonne est partiellement véhiculée en l'étiquetant avec le nom du domaine correspondant.

Je pense que cela dépend de la manière dont votre candidature est élaborée. Si vous utilisez ORM ou concevez vos tableaux pour représenter des objets, l'option 1 peut être pour vous.

J'aime coder la base de données comme sa propre couche. Je contrôle tout et l'application n'appelle que les procédures stockées. Il est agréable d'avoir des ensembles de résultats avec des noms de colonnes complets, en particulier lorsqu'il y a de nombreuses tables jointes et de nombreuses colonnes renvoyées. Avec ce type d'application, j'aime l'option 2. J'aime vraiment voir les noms de colonnes correspondre sur les jointures. J'ai travaillé sur d'anciens systèmes où ils ne correspondaient pas et c'était un cauchemar,

Aucune des deux conventions ne fonctionne dans tous les cas, alors pourquoi en avoir une? Utiliser le bon sens...

par exemple, pour une table auto-référencée, quand il y a plus d'une colonne FK qui auto-référence le PK de la même table, vous DEVEZ violer les deux "standards", puisque les deux colonnes FK ne peuvent pas être nommées de la même manière ... par exemple , EmployeeTable avec EmployeeId PK, SupervisorId FK, MentorId Fk, PartnerId FK, ...

Je reconnais qu'il y a peu de choix entre eux. Pour moi, une chose beaucoup plus importante à propos de l'une ou l'autre norme est la partie «standard».

Si les gens commencent à «faire leur propre chose», ils devraient être bloqués par leurs nethers. A MON HUMBLE AVIS :)

Avez-vous envisagé ce qui suit?

Primary Table (Employee)   
Primary Key is PK_Employee

Foreign table (Event)  
Foreign key is called FK_Employee

La convention que nous utilisons là où je travaille est assez proche de A, à l'exception du fait que nous nommons les tables au pluriel (c'est-à-dire «employés») et utilisons des traits de soulignement entre le nom de la table et de la colonne. L'avantage est que pour faire référence à une colonne, il s'agit soit de "employee _ id" soit de "Employees.id", selon la manière dont vous souhaitez y accéder. Si vous avez besoin de spécifier de quelle table provient la colonne, "Employees.employees _ id" est définitivement redondant.

Si vous regardez le code de l'application, pas seulement les requêtes de base de données, certaines choses me semblent claires:

1. Les définitions de table correspondent généralement directement à une classe qui décrit un objet, elles doivent donc être au singulier. Pour décrire une collection d'un objet, j'ajoute généralement "Array" ou "List" ou "Collection" au nom singulier, car il indique plus clairement que l'utilisation de pluriels indique non seulement qu'il s'agit d'une collection, mais quel type de collection c'est. Dans cette vue, je vois un nom de table comme non pas le nom de la collection, mais le nom du type d'objet dont il est une collection. Un DBA qui n'écrit pas de code d'application peut manquer ce point.

2. Les données que je traite utilisent souvent «ID» à des fins d'identification non essentielles. Pour éliminer la confusion entre les "ID" clés et les "ID" non clés, pour le nom de la clé primaire, nous utilisons "Key" (c'est ce que c'est, n'est-ce pas?) Avec le préfixe du nom de la table ou une abréviation de le nom de la table. Ce préfixe (et je le réserve uniquement pour la clé primaire) rend le nom de clé unique, ce qui est particulièrement important car nous utilisons des noms de variables identiques aux noms de colonnes de la base de données, et la plupart des classes ont un parent, identifié par le nom de la clé parent. Ceci est également nécessaire pour s'assurer qu'il ne s'agit pas d'un mot-clé réservé, ce que "Key" seul est. Pour faciliter la cohérence des noms de variables clés et fournir des programmes qui effectuent des jointures naturelles, les clés étrangères ont le même nom que celui utilisé dans la table dans laquelle elles sont la clé primaire. J'ai rencontré plus d'une fois des programmes qui fonctionnent beaucoup mieux de cette façon en utilisant des jointures naturelles. Sur ce dernier point, j'avoue un problème avec les tables d'auto-référencement, que j'ai utilisé. Dans ce cas, je ferais une exception à la règle de dénomination de clé étrangère. Par exemple, j'utiliserais ManagerKey comme clé étrangère dans la table Employee pour pointer vers un autre enregistrement de cette table.

J'aime la convention n ° 2 - en recherchant ce sujet et en trouvant cette question avant de publier la mienne, je suis tombé sur le problème où:

Je sélectionne * à partir d'une table avec un grand nombre de colonnes et je la joins à une deuxième table qui a de la même manière un grand nombre de colonnes. Les deux tables ont une colonne "id" comme clé primaire, ce qui signifie que je dois sélectionner spécifiquement chaque colonne (pour autant que je sache) afin de rendre ces deux valeurs uniques dans le résultat, c'est-à-dire:

SELECT table1.id AS parent_id, table2.id AS child_id

Bien que l'utilisation de la convention n ° 2 signifie que j'aurai toujours des colonnes dans le résultat avec le même nom, je peux maintenant spécifier l' id dont j'ai besoin (parent ou enfant) et, comme Steven Huwig l'a suggéré, l' USINGinstruction simplifie encore les choses.

J'ai toujours utilisé userId comme PK sur une table et userId sur une autre table comme FK. Je pense sérieusement à utiliser userIdPK et userIdFK comme noms pour identifier les uns des autres. Cela m'aidera à identifier PK et FK rapidement lorsque je regarde les tables et il semble que cela effacera le code lors de l'utilisation de PHP / SQL pour accéder aux données, ce qui facilitera la compréhension. Surtout quand quelqu'un d'autre regarde mon code.

J'utilise la convention n ° 2. Je travaille maintenant avec un modèle de données hérité où je ne sais pas ce que signifie une table donnée. Où est le mal d'être verbeux?

Que diriez-vous de nommer la clé étrangère

role_id

où role est le rôle de l'entité référencée par rapport à la table à portée de main. Cela résout le problème de la référence récursive et de plusieurs fks à la même table.

Dans de nombreux cas, sera identique au nom de la table référencée. Dans ce cas, il devient identique à l'une de vos propositions.

En tout cas, avoir de longs arguments est une mauvaise idée

"Où dans" employé INNER JOIN order ON order.employee_id = employee.id "y a-t-il besoin d'une qualification supplémentaire?".

Il n'y a pas besoin de qualification supplémentaire car la qualification dont j'ai parlé est déjà là.

"la raison pour laquelle un utilisateur professionnel se réfère à l'ID de commande ou à l'ID d'employé est de fournir un contexte, mais au niveau de la base de données, vous avez déjà un contexte parce que vous référez à la table".

Je vous en prie, dites-moi, si la colonne est nommée «ID», alors comment se fait exactement ce «renvoi [sic] à la table», à moins de qualifier cette référence à la colonne ID exactement de la manière dont j'ai parlé?