À titre d'exemple, J'ai un 3 tables:Devrais-je utiliser la clé primaire ici?
School: ID int, Name varchar
Student: ID int, Name varchar
StudentInSchool: StudentID int, SchoolID int
Maintenant, la question est si je devrais mettre une colonne ID int avec une clé primaire sur elle dans le tableau StudentInSchool? Si oui, pourquoi?
Sera-t-il utile dans l'indexation?
Toute aide appréciée.
Personnellement, je crée composite PK (StudentID et SchoolID) sur tel junction tables. Cela garantit également l'unicité.
Si, toutefois, l'unicité n'est pas requise, vous devrez ajouter une colonne ID pour identifier chaque ligne de façon unique. En règle générale, l'ajout d'une colonne séparée ID ne va pas aider beaucoup: très peu de requêtes (le cas échéant) utilisera réellement cette colonne. En ce qui concerne les performances, vous pouvez créer un index séparé pour chaque colonne et tout ira bien.
Créer une clé primaire sur et un index secondaire sur SchoolID, ou vice versa, en fonction de la condition de recherche utilisée le plus souvent.
Si votre table est index organisé (ORGANIZATION INDEX Oracle, CLUSTERED dans SQL Server, InnoDB à MySQL), l'index secondaire aura un PRIMARY KEY comme une partie gauche et, par conséquent, toutes les informations peuvent être extrait de l'indice.
La réponse est, cela dépend. Dans la plupart des cas, la réponse est "Non": une clé primaire composée de (StudentID, SchoolID) suffira. Mais si cette table d'intersection commence à acquérir d'autres données connexes (par exemple, date d'adhésion, date de fin) et/ou devient parent de tables liées (par exemple enregistrement de présence) alors vous voudrez ou devez le traiter comme un table régulière. Dans ce cas, (StudentID, SchoolID) devient une clé d'entreprise (c'est-à-dire toujours unique) et vous ajoutez une clé primaire synthétique (ou substitut) d'Id ou autre.
En termes d'intégrité des données pures: non. Il est parfaitement suffisant de définir la clé primaire en tant que (StudentID, SchoolID). Cependant, vous ne dites pas quel RDBMS vous utilisez. Il se peut que, pour certaines d'entre elles, une seule colonne d'ID aboutisse à des plans de requête plus efficaces.
Dans le cas de SQL Server, une clé primaire composite de deux entiers est très efficace et aucun autre index ne doit être requis sur les deux colonnes.
Dans cet exemple, sauf si la table StudentInSchool doit avoir d'autres attributs, par ex. horodatages pour quand l'étudiant était dans cette école pour faire face à des mouvements, je ne l'utiliserais pas et je mettrais le champ schoolID dans la table des étudiants et le définir comme une clé étrangère là.
Mais si c'est la conception, alors oui, vous ne perdrez rien en mettant une clé primaire sur la table StudentInSchool.
Vous pouvez combiner StudentID et SchoolID à une clé primaire.
Il existe certaines règles générales qui décrivent quand utiliser des index. Lorsque traitant des tables relativement petites, les index n'améliorent pas les performances. Dans les index généraux améliorent les performances lorsqu'ils sont créés sur des champs utilisés dans les jointures de table. Utilisez des index lorsque la plupart des requêtes de votre base de données renvoient relativement petits ensembles de données, car si vos requêtes récupèrent la plupart des données la plupart du temps, les index ralentir réellement la récupération de données. Utilisez les index pour les colonnes ayant plusieurs valeurs différentes (il n'y a pas beaucoup de valeurs répétées dans la colonne). Bien que les index améliorer la recherche performances, ils ralentissent les mises à jour, et cela pourrait être quelque chose vaut compte tenu.
Source: SQL Indexes
Ok je pense qu'il ya quelque chose qui manque dans l'affectation, donc je vais essayer avec ma pauvre connaissance du monde réel: o)
Quels sont les étudiants? Ils vont à l'école (s), ils peuvent étudier dans plus d'une école (en particulier les universités), ils peuvent même répéter la même école plus tard, etc
Est-ce que la table de jonction telle quelle (avec PK sur les deux id) suffit modéliser ces relations?
réponse courte: non
longue réponse: toujours pas, mais pour sous-ensemble des cas simples, il suffit (est à vous l'un d'eux?).
Si vous souhaitez étendre DB ultérieurement pour tous ces cas, PK de substitution (votre ID) sera nécessaire. Je mettrais une carte d'identité là-bas si j'avais un doute que cela pourrait être nécessaire (car il n'y a pas grand chose à perdre).
Comme indiqué dans la première phrase - réponse correcte est: "Nous ne savons pas" car les exigences et le contexte de l'application sont manquants.
+1. Je prends la même approche – Alex
Dépend de la cardinalité de la relation que nous voulons décrire en utilisant la table de jonction. L'application de la relation un-à-un peut se retourner contre nous lorsque nous essayons de modéliser le monde réel. –