Convention de nommage de clé primaire / étrangère

Dans notre groupe de développement, nous avons un débat sur 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 (je préfère donc l’option 1 ci-dessus). D’un sharepoint vue conceptuel, cela correspond à de nombreuses pratiques recommandées dans d’autres langages, où vous n’utilisez pas le nom de l’object dans ses noms de propriété. Je pense que nommer la clé étrangère EmployeeID (ou Employee_ID peut être préférable) indique au lecteur qu’il s’agit de la colonne ID de la table Employee .

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

En outre, je pense qu’il est inutile 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 atsortingbut de cette entité, vous la considérez comme l’atsortingbut ID de l’ Employee . pas l’atsortingbut EmployeeID d’un employé. Je ne vais pas demander à mon collègue quel est son PersonAge ou PersonGender . 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. Je suis intéressé par de nouvelles outlook.

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

Jeff Atwood a eu un excellent article il y a quelque temps sur ce sujet. Fondamentalement, les gens débattent et discutent le plus furieusement des sujets sur lesquels ils ne peuvent pas être prouvés. Ou sous un angle différent, les sujets qui ne peuvent être gagnés que par des arguments de résistance basés sur l’endurance du style filibuster.

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

EDIT: Si vous voulez vous amuser, demandez-leur de spécifier en détail 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 en SQL pour économiser de la saisie et du bruit:

 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 manière dont le modèle relationnel a été conçu.

La signification de chaque colonne est partiellement transmise en l’étiquetant avec le nom du domaine correspondant.

Je pense que cela dépend de la façon dont votre application est mise en place. Si vous utilisez ORM ou concevez vos tables pour représenter des objects, l’option 1 peut être pour vous.

J’aime coder la firebase database comme sa propre couche. Je contrôle tout et l’application appelle simplement les procédures stockées. Il est intéressant d’avoir des jeux de résultats avec des noms de colonnes complets, en particulier lorsque plusieurs tables sont jointes et que de nombreuses colonnes sont renvoyées. Avec ce type d’application, j’aime l’option 2. J’aime vraiment voir les noms de colonnes correspondre aux jointures. J’ai travaillé sur de vieux 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 référence automatiquement la PK de la même table, vous DEVEZ violer les deux “standards”, car les deux colonnes FK ne peuvent pas être nommées , EmployeeTable avec EmployeeId PK, SupervisorId FK, MentorId Fk, PartnerId FK, …

Je suis d’accord qu’il y a peu de choix entre eux. Pour moi, une partie beaucoup plus importante de l’une ou l’autre norme est la partie “standard”.

Si les gens commencent à «faire leur propre chose», ils doivent être attachés par leurs amis. A MON HUMBLE AVIS 🙂

Si vous consultez le code de l’application, et pas seulement les requêtes de firebase database, certaines choses me semblent claires:

  1. Les définitions de table correspondent généralement directement à une classe qui décrit un object, elles doivent donc être singulières. Pour décrire une collection d’un object, j’ajoute habituellement “Array” ou “List” ou “Collection” au nom singulier, car il est plus clair que d’utiliser des pluriels, ce qui indique non seulement qu’il s’agit d’une collection, mais aussi c’est. Dans cette vue, je vois un nom de table comme non le nom de la collection, mais le nom du type d’object dont il s’agit d’une collection. Un administrateur de firebase database qui n’écrit pas de code d’application risque de manquer ce point.

  2. Les données que je traite utilisent souvent “ID” à des fins d’identification non-clés. Pour éliminer la confusion entre la clé “ID” 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 nom de la table ou une abréviation de le nom de la table. Ce préfixe (et je ne le réserve que pour la clé primaire) rend le nom de clé unique, ce qui est particulièrement important car nous utilisons des noms de variable identiques aux noms de colonne de la firebase database et la plupart des classes ont un parent, identifié par le nom de la clé parente. Cela est également nécessaire pour s’assurer qu’il ne s’agit pas d’un mot clé réservé, ce qui est la seule clé. Pour faciliter la cohérence des noms de variables clés et fournir des programmes exécutant des jointures naturelles, les clés étrangères portent le même nom que celui utilisé dans la table dans laquelle elles constituent la clé primaire. J’ai plus d’une fois rencontré des programmes qui fonctionnent beaucoup mieux de cette façon en utilisant des jointures naturelles. Sur ce dernier point, j’admets un problème avec les tables auto-référencées que j’ai utilisées. Dans ce cas, je ferais une exception à la règle de dénomination de la clé étrangère. Par exemple, j’utiliserais ManagerKey en tant que 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 poster la mienne, je suis tombé sur le problème:

Je sélectionne * dans une table avec un grand nombre de colonnes et je l’associe à une seconde table qui comporte également un grand nombre de colonnes. Les deux tables ont une clé “id” en tant que 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, à savoir:

 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 du même nom, je peux maintenant spécifier quel identifiant j’ai besoin (parent ou enfant) et, comme l’a suggéré Steven Huwig, l’instruction USING simplifie les choses.

J’ai toujours utilisé userId en tant que PK sur une table et userId sur une autre table en tant que FK. Pensez sérieusement à utiliser userIdPK et userIdFK comme noms pour identifier l’un de l’autre. Cela m’aidera à identifier rapidement PK et FK en regardant les tables et il semble que cela efface le code lors de l’utilisation de PHP / SQL pour accéder aux données, ce qui facilite la compréhension. Surtout quand quelqu’un regarde mon code.

La convention que nous utilisons là où je travaille est assez proche de A, sauf que nous nommons des 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 de cela est que, pour faire référence à une colonne, il s’agit de “employee _ id” ou “employees.id”, selon la manière dont vous voulez y accéder. Si vous avez besoin de spécifier de quelle table provient la colonne, “employees.employees _ id” est définitivement redondant.

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

Comment nommer la clé étrangère

role_id

où rôle est le rôle que l’entité référencée a par rapport à la table en question. Cela résout le problème de la référence récursive et de plusieurs ressources sur 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, de longs arguments sont une mauvaise idée

Avez-vous considéré ce qui suit?

 Primary Table (Employee) Primary Key is PK_Employee Foreign table (Event) Foreign key is called FK_Employee 

“Où dans” employé INNER JOIN commande-t-il ON order.employee_id = employee.id “Faut-il 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 fait référence à l’ID de commande ou à l’ID d’employé est de fournir un contexte, mais à un niveau de firebase database, vous avez déjà un contexte car vous êtes référé à la table”.

Priez, dites-moi, si la colonne est nommée ‘ID’, alors comment cela se fait-il, à moins de qualifier cette référence à la colonne ID exactement de la manière dont j’ai parlé?