2009-05-09 12 views
5

Selon la définition, est utilisé pour de nombreuses à plusieurs relations, quand il est utilisé comme celui-ci un Junction Table (table de bridge/table de liaison):Une table de jonction (table de jointure) peut-elle également être utilisée pour une relation un-à-plusieurs?

CREATE TABLE Users 
(
UserLogin varchar(50) PRIMARY KEY, 
UserPassword varchar(50) NOT NULL, 
UserName varchar(50) NOT NULL 
) 


CREATE TABLE Permissions 
(
PermissionKey varchar(50) PRIMARY KEY, 
PermissionDescription varchar(500) NOT NULL 
) 


--This is the junction table. 
CREATE TABLE UserPermissions 
(
UserLogin varchar(50) REFERENCES Users (UserLogin), 
PermissionKey varchar(50) REFERENCES Permissions (PermissionKey), 
PRIMARY KEY (UserLogin, PermissionKey) 
) 

Mais ne pourrait-il être utilisé aussi tout aussi facilement pour une relation un à plusieurs, comme dans cet exemple dans lequel un utilisateur est associé à de nombreuses commandes:

(je ne comprends pas les bases de données si bien que s'il vous plaît me corriger si je l'ai mal compris quelque chose .)

CREATE TABLE Users 
(
UserLogin varchar(50) PRIMARY KEY, 
UserPassword varchar(50) NOT NULL, 
UserName varchar(50) NOT NULL 
) 


CREATE TABLE Orders 
(
OrderKey varchar(50) PRIMARY KEY, 
OrderDescription varchar(500) NOT NULL 
) 


--This is the junction table. 
CREATE TABLE UserOrders 
(
UserLogin varchar(50) REFERENCES Users (UserLogin), 
OrderKey varchar(50) REFERENCES Orders (OrderKey), 
PRIMARY KEY (UserLogin, OrderKey) 
) 

Répondre

6

Oui, mais vous laissez la vérification que ce n'est pas beaucoup pour l'application, au lieu de l'appliquer dans la base de données.

+0

Voulez-vous dire que c'est mauvais? –

+0

Parfois, cela peut être pratique si vous voulez avoir la même structure de tables db mais décider du type de relation dans l'application: un à plusieurs ou plusieurs à plusieurs. (en tant que paramètre) Il y a des moments où vous développez une relation de un à plusieurs en sachant qu'il est très susceptible de changer de plusieurs à plusieurs. –

+0

Je vois. Et si vous vouliez appliquer la fonction un-à-plusieurs ou plusieurs-à-plusieurs dans la base de données, vous utilisez plutôt un type de contrainte? –

8

Il n'y a aucune raison pour laquelle une table de jonction ne pouvait pas être utilisé pour un à plusieurs. La question est généralement celle de la performance. Pourquoi faire en sorte que la base de données rejoigne une table supplémentaire lorsqu'elle n'est pas nécessaire?

+2

Si la table de jonction, ou l'association entre ces tables, est rarement interrogée ou jointe, serait-il alors plus avantageux d'avoir une table de jonction peu encombrante? –

1

Une fois que vous avez construit une table, elle n'a vraiment pas de type de table "Junction", de table "associative", de table "join" - c'est juste une table. Nous utilisons ces termes pour décrire une raison spécifique pour laquelle une entité (et une table résultante) a été créée initialement. Les entités associatives sont créées, initialement, pour résoudre une situation plusieurs-à-plusieurs. Mais ces tables ont souvent leurs propres attributs (comme le temps de l'association, la raison de l'association, etc.). Donc SQL Server, Oracle ou votre code n'a aucune raison de savoir pourquoi une table a été créée ... juste que c'est une table. D'un point de vue technique, il n'y a vraiment aucune différence entre une table associative et n'importe quelle autre table.

Ces tables peuvent donc remplir n'importe quel rôle que n'importe quelle autre table peut remplir. Il n'y a pas de règles sur la manière dont les autres tables peuvent également être liées à ces tables.

+0

Merci. –

3

Ce serait beaucoup à plusieurs:

CREATE TABLE UserOrders 
(UserLogin varchar(50) REFERENCES Users (UserLogin), 
OrderKey varchar(50) REFERENCES Orders (OrderKey), 
PRIMARY KEY (UserLogin, OrderKey)); 

Ce serait un à plusieurs (un utilisateur a plusieurs commandes):

CREATE TABLE UserOrders 
(UserLogin varchar(50) REFERENCES Users (UserLogin), 
OrderKey varchar(50) REFERENCES Orders (OrderKey), 
PRIMARY KEY (OrderKey)); 

Notez la différence dans la clé primaire contrainte.

0

Vous pouvez appliquer une contrainte de "un" dans la table jointure/jonction en ajoutant une contrainte unique (ou en faisant la clé primaire de la table de jointure, car elle identifie elle-même la relation) à la colonne étrangère clé du "plusieurs" côté. C'est parce que vous voulez que les rwos de tous les côtés aient une seule relation et que les relations soient indiquées dans la table join/junction.

0

Je pense que vous avez le mauvais concept - Voici l'explication simple si elle pouvait aider: Pour plusieurs-plusieurs entre deux tables (par exemple, A et B), nous devons prendre l'aide de une table de jonction (par exemple, table c) qui aura une relation un-plusieurs avec les deux tables A et B.Qu'en est-il dans une situation où la clé étrangère sera la plupart du temps NULL?