Faire un lien tables besoin d'une source de champ de clé primaire?

Pour un véritable lien tables, en général, ils n'existent pas en tant qu'objet d'entités dans mes modèles objet. Ainsi, la clé de substitution n'est jamais utilisée. Le support d'un élément à partir d'une collection de résultats en suppression d'un élément à partir d'un lien de relation où les deux clés étrangères sont connus (Person.Siblings.Remove(Sibling) ou Person.RemoveSibling(Sibling) qui est correctement traduite à la couche d'accès aux données que usp_Person_RemoveSibling(PersonID, SiblingID)).

Comme Mike l'a mentionné, si ce n'est de devenir une véritable entité dans votre modèle d'objet, alors il mérite un ID. Cependant, même avec l'ajout d'temporelle des facteurs comme effective de début et dates de fin de la relation et des choses comme ça, il n'est pas toujours clair. Par exemple, la collection peut avoir une date d'entrée en vigueur associés au niveau global, la relation elle-même n'est pas encore devenu une entité avec toutes les propriétés exposées.

Je tiens à ajouter que vous pourriez avoir besoin de la table indexée à la fois des moyens sur les deux colonnes de clé étrangère.

Si c'est un vrai plusieurs-à-plusieurs table de jointure, puis vidage élément de colonne id (à moins que votre ORM en nécessite un. dans ce cas, vous avez à décider si votre intelligence va l'emporter sur votre pratique).

Mais je trouve que la vraie joindre les tables sont assez rares. Elle n'est généralement pas longtemps avant que je commence à vouloir mettre quelques autres données dans la table. Parce que j'ai presque toujours le modèle, ces tables de jointure comme des entités à partir du début et de mettre un id de là.

Composite PK et désactiver l'agrégation.

j'ai utilisé les deux, le seul avantage de l'utilisation de la premier modèle (avec l'uid) est que vous pouvez transporter l'identifiant comme un nombre, alors que dans certains cas, vous auriez à le faire certains de concaténation de chaîne avec la clé composite pour le transport de autour de.

je suis d'accord qu'en n'indexant pas les clés étrangères est une mauvaise idée, selon la manière dont vous allez.

Si vous avez besoin de traverser la table de jointure "dans les deux sens", c'est de commencer avec un table1fk ou un table2fk clé seulement, vous pourriez envisager d'ajouter un deuxième, inversée, de l'indice composite.

ADD KEY ('table2fk', 'table1fk')

Il y a quelque chose qui s'appelle l'identification et la non-identification de la relation. Avec l'identification des relations de la FK est une partie de la PK dans le plusieurs-à-plusieurs table. Par exemple, disons que nous avons des tables Person, Company et plusieurs-à-plusieurs table Employment. Dans une identification de relation, les deux fk PersonID et CompanyID font partie de la pk, donc nous ne pouvons pas répéter PersonID, CompanyID combinaison.

TABLE Employment(PersonID int (PK,FK), CompanyID int (PK,FK))

Maintenant, supposons que nous voulons capturer l'histoire de l'emploi, de sorte qu'une personne peut quitter l'entreprise, du travail ailleurs et revenir à la même entreprise plus tard. La relation est non-identifier ici, la combinaison de PersonID, CompanyID pouvez maintenant répéter, de sorte que le tableau devrait ressembler à quelque chose comme:

TABLE Employment(EmploymentID int (PK), PersonID int (FK), CompanyID int (FK), 
                     FromDate datetime, ToDate datetime)