Une ou Deux Clés Primaires dans plusieurs-à-Plusieurs Table?

Question

J'ai les tables suivantes dans ma base de données qui ont un plusieurs-à-plusieurs relations, ce qui est exprimé par une connexion de table qui a les clés étrangères pour les clés primaires de chacune des tables principales:

• Widget:WidgetID (PK), Titre, Prix
• Utilisateur:UserID (PK), FirstName, LastName

Supposons que chaque Utilisateur Widget combinaison est unique.Je vois deux options pour la structure de connexion de la table qui définit la relation de données:

1. UserWidgets1:UserWidgetID (PK), WidgetID (FK), l'Identifiant (FK)
2. UserWidgets2:WidgetID (PK, FK), l'Identifiant (PK, FK)

L'Option 1 a une seule colonne de la Clé Primaire.Toutefois, cela semble inutile, car les seules données stockées dans le tableau est la relation entre les deux tables principales, et cette relation elle-même peut constituer une clé unique.Conduisant ainsi à l'option 2, qui a deux colonnes de clé primaire, mais perd la colonne identifiant unique que l'option 1 est.Je pourrais aussi éventuellement ajouter un à deux colonnes, index unique (WidgetID, UserID) à la première table.

Est-il une vraie différence entre les deux en terme de performance, ou aucune raison de préférer une approche sur l'autre pour la structuration de la UserWidgets plusieurs-à-plusieurs table?

Answer 1

Vous n'avez qu'une clé primaire dans les deux cas.Le second est ce qu'on appelle une clé composée.Il n'y a aucune bonne raison de l'introduction d'une nouvelle colonne.Dans la pratique, vous devrez garder un index unique sur toutes candidat clés.Ajout d'une nouvelle colonne vous achète rien mais les frais de maintenance.

Allez à l'option 2.

Answer 2

Personnellement, J' serait ont l'synthétique/colonne de clé de substitution dans plusieurs-à-plusieurs tables pour les raisons suivantes:

• Si vous avez utilisé numérique synthétique clés dans vos tables entité ayant alors le même sur la relation des tables permet de maintenir la cohérence dans la conception et la convention de nommage.
• Il peut être le cas dans l'avenir, plusieurs-à-plusieurs table elle-même devient une entité mère à un subordonné de l'entité qui a besoin d'une référence unique à un individu de ligne.
• Il n'est pas vraiment à utiliser beaucoup d'espace disque supplémentaire.

La synthèse la clé n'est pas un remplacement pour le naturel, composé de la clé, ni le PRIMARY KEY pour que la table juste parce que c'est la première colonne de la table, donc je suis partiellement d'accord avec Josh Berkus article.Cependant, je ne pense pas que les clés sont toujours de bons candidats pour PRIMARY KEY's et ne devrait certainement pas être utilisés s'ils sont utilisés comme clés étrangères dans d'autres tables.

Answer 3

Option 2 utilise un simple compund touche, l'option 1 utilise un clé de substitution.L'Option 2 est préféré dans la plupart des scénarios, et est proche du lreational modèle en ce qu'il est un bon candidat à la clé.

Il y a des situations où vous souhaiterez peut-être utiliser une clé de substitution (Option 1)

1. Vous n'êtes pas que la clé composée est une bonne clé candidate au fil du temps.En particulier avec les données temporelles (des données qui changent au fil du temps).Que faire si vous voulez ajouter une autre ligne à l'UserWidget table avec le même nom d'utilisateur et WidgetId?Penser à l'Emploi(Employé,Employé) - il serait de travailler dans la plupart des cas, sauf si quelqu'un s'est remise au travail pour le même employeur, à une date ultérieure
2. Si vous créez des messages et/ou des transactions d'affaires ou quelque chose de semblable qui nécessitent une plus facile de la clé à utiliser pour l'intégration.La réplication peut-être?
3. Si vous souhaitez créer vos propres mécanismes de vérification (ou similaires) et ne veut pas les clés pour obtenir trop longtemps.

En règle générale, lors de la modélisation de données, vous trouverez que la plupart les entités associatives (plusieurs à plusieurs) sont le résultat d'un événement.Personne prenne l'emploi, l'élément est ajouté au panier, etc.La plupart des événements ont une dépendance temporelle sur l'événement, où la date ou l'heure est pertinent - dans ce cas, une clé de substitution peut être la meilleure alternative.

Donc, prenez l'option 2, mais assurez-vous que vous avez le modèle complet.

Answer 4

Je suis d'accord avec les réponses précédentes, mais j'ai une remarque à ajouter.Si vous souhaitez ajouter plus d'informations à la relation et permettre à davantage de relations entre les deux mêmes entités, vous avez besoin d'une option.

Par exemple, si vous souhaitez suivre toutes les fois où l'utilisateur 1 a utilisé le widget 664 dans le userwidget table le nom d'utilisateur et widgetid n'est pas unique plus.

Answer 5

Quel est l'avantage d'une clé primaire dans ce scénario?Envisager la possibilité de sans clé primaire:UserWidgets3:WidgetID (FK), l'Identifiant (FK)

Si vous voulez unicité puis utiliser la clé composée (UserWidgets2) ou d'une contrainte d'unicité.

Les performances habituelles avantage d'avoir une clé primaire est que vous avez souvent requête de la table par la clé primaire, ce qui est rapide.Dans le cas de plusieurs-à-plusieurs tables, vous n'avez pas l'habitude de la requête par la clé primaire, donc il n'y a pas de gain de performances.Plusieurs-à-plusieurs tables sont interrogés par leurs clés étrangères, de sorte que vous devriez envisager d'ajouter des index sur WidgetID et nom d'utilisateur.

Answer 6

L'Option 2 est la bonne réponse, à moins d'avoir une très bonne raison d'ajouter un substitut à la touche numérique (ce que vous avez fait dans l'option 1).

De substitution touche numérique, les colonnes ne sont pas des "clés primaires'.Les clés primaires sont techniquement l'un de la combinaison de colonnes qui identifient de façon unique un enregistrement dans une table.

Quiconque construit une base de données devraient lire cet article http://it.toolbox.com/blogs/database-soup/primary-keyvil-part-i-7327 par Josh Berkus de comprendre la différence entre la mère porteuse numérique colonnes clés primaires et clés.

Dans mon expérience, la seule vraie raison pour ajouter un substitut à la touche numérique pour votre table est si votre clé primaire est un composé clé et doit être utilisé comme une référence de clé étrangère dans une autre table.Ensuite, il ne vous même de penser à ajouter une colonne à la table.

Chaque fois que je vois une structure de base de données où chaque table a une colonne' id les chances sont qu'il a été conçu par quelqu'un qui n'apprécie pas le modèle relationnel et qu'il va invariablement d'afficher un ou plusieurs des problèmes identifiés en matière de Josh article.

Answer 7

Je voudrais aller avec les deux.

Écoutez-moi:

Le composé de la clé est évidemment la belle, bonne façon de procéder dans la mesure où reflétant le sens de vos données.Pas de question.

Cependant:J'ai eu toutes sortes de difficultés à faire hibernate fonctionner correctement si vous utilisez un seul généré clé primaire une clé de substitution.

Donc, je voudrais utiliser une logique et physique des données modèle.La logique est la clé composée.Le modèle physique - qui met en œuvre le modèle logique - a la clé de substitution et les clés étrangères.

Answer 8

Étant donné que chaque Utilisateur Widget combinaison est unique, vous devez vous représenter que, dans votre table en faisant la combinaison unique.En d'autres termes, allez à l'option 2.Sinon vous pourriez avoir deux entrées avec le même widget et Id utilisateur, mais différent de l'utilisateur-Id widgets.

Answer 9

Le userwidgetid dans le premier tableau n'est pas nécessaire, car comme vous l'avez dit, l'originalité vient de la combinaison de la widgetid et le nom d'utilisateur.

Je voudrais utiliser le deuxième tableau, garder le foriegn clés et ajouter un index unique sur widgetid et nom d'utilisateur.

Donc:

userwidgets( widgetid(fk), userid(fk),
             unique_index(widgetid, userid)
)

Il ya un certain gain de performance n'ayant pas le supplément de clé primaire, comme la base de données n'aurait pas besoin de calculer l'index de la clé.Dans le modèle ci-dessus bien que cet indice (par le biais de la unique_index) est toujours calculé, mais je crois que c'est plus facile à comprendre.