Première convention de nommage clé étrangère /

Question

Dans notre dev groupe, nous avons un débat qui fait rage au sujet de la convention d'affectation de noms pour les Clés Primaires et Étrangères. Il n'y a fondamentalement deux écoles de pensée au sein de 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 répéter le nom de la table dans l'une des colonnes (Donc je préfère l'option 1 ci-dessus). Sur le plan conceptuel, il est compatible avec un grand nombre de 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 la mention de la clé étrangère Employé (ou Employee_ID peut-être mieux) indique au lecteur qu'il est la colonne ID de la Table Employee.

Certains d'autres préfèrent l'option 2 où vous le nom de la clé primaire préfixés par le nom de la table, de sorte que le nom de la colonne est la même tout au long de la base de données. Je vois ce point, mais vous ne pouvez pas distinguer une clé primaire d'une clé étrangère.

Aussi, je pense que c'est redondant d'avoir le nom de la table dans la colonne nom, parce que si vous pensez de la table comme une entité et d'une colonne comme une propriété ou un attribut de l'entité, pensez-vous que l'attribut ID de l'Employé, et non l'attribut d'Employé d'un employé. Je ne vais pas faire une demande à mon collègue que son Personnage ou PersonGender est. Je lui demande ce que son Âge.

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

Answer 1

Si les deux colonnes ont le même nom dans les deux tables (convention n ° 2), vous pouvez utiliser l'AIDE de la syntaxe SQL pour enregistrer la saisie et réutilisable bruit:

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

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

La signification de chaque colonne est partiellement transmis par marquage avec le nom de domaine correspondant.

Answer 2

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

Jeff Atwood avait un excellent article d'un moment de retour sur ce sujet. En fait, les gens débattre et discuter le plus furieusement ces sujets, qu'ils ne peuvent pas tromper. Ou à partir d'un angle différent, les sujets qui ne peut être gagné que par le biais de l'obstructionnisme style d'endurance en fonction de dernier homme debout arguments.

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

EDIT: Si vous voulez vous amuser, demandez-leur de préciser, dans la durée, pourquoi leur méthode est supérieure pour les références de table.

Answer 3

Je pense que cela dépend de comment vous demande est mis en place. Si vous utilisez l'ORM ou la conception de vos tables pour représenter des objets, puis l'option 1 est pour vous.

J'aime le code de la base de données dans son propre calque. Je contrôle tout et l'application des appels de procédures stockées. Il est agréable d'avoir des ensembles de résultats à remplir la colonne des noms, surtout quand il y a beaucoup de tables jointes et de nombreuses colonnes retournées. Avec ce stype de l'application, j'ai comme dans l'option 2. J'ai vraiment envie de voir la colonne de noms de match sur les jointures. J'ai travaillé sur de vieux systèmes où ils n'ont pas de match et c'était un cauchemar,

Answer 4

Je conviens 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 doivent être attachés par leurs nethers. A MON HUMBLE AVIS :)

Answer 5

Si vous êtes à la recherche au code de l'application, pas seulement les requêtes de base de données, certaines choses semblent claires pour moi:

1. Définitions de Table le plus souvent directement de la carte à une classe qui décrit un objet, de sorte qu'ils devraient être au singulier. Pour décrire une collection d'un objet, je l'habitude d'ajouter "Tableau" ou "Liste" ou "Collection" au nom singulier, plus clairement que l'utilisation des pluriels indique non seulement que c'est une collection, mais quel type de collection c'est. De ce point de vue, je vois un nom de table comme le nom de la collection, mais le nom du type de l'objet dont elle est l'une collection. Un DBA qui n'a pas d'écrire le code de l'application peut manquer à ce point.

2. Les données que j'ai traiter avec souvent utilise "ID" pour les non-clé des fins d'identification. Pour éliminer la confusion entre la touche "ID"s et non-clé "ID"s, pour la clé primaire nom, nous utilisons des "Clés" (c'est ce qu'il est, n'est-ce pas?) préfixe le nom de la table ou une abréviation du nom de la table. Cette préfixation (et je réserve ce que pour la clé primaire) en fait le nom de la clé unique, ce qui est particulièrement important, car nous utiliser des noms de variable sont les mêmes que la base de données des noms de colonne, 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 n'est pas un mot clé réservé, qui "Touche" tout seul. Afin de faciliter le maintien des noms de variables uniformes, et de fournir à des programmes qui ne les jointures naturelles, les clés étrangères ont le même nom est utilisé dans le tableau dans lequel elles sont la clé primaire. J'ai plus d'une fois rencontré des programmes qui fonctionnent beaucoup mieux de cette façon en utilisant les jointures naturelles. Sur ce dernier point, j'avoue un problème avec l'auto-référencement des tableaux, que j'ai utilisé. Dans ce cas, je ferais une exception pour la clé étrangère de la règle de nommage. Par exemple, je voudrais utiliser ManagerKey de clé étrangère dans la table des Employés à point à un autre enregistrement dans cette table.