¿Se puede usar también una tabla de unión (tabla de unión) para una relación de uno a varios?

Question

De acuerdo con la definición, un (/ tabla de enlace mesa de bridge) Junction Table se utiliza para las relaciones de muchos a muchos, cuando se usa de esta manera:

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) 
) 

Pero ¿no podría también usarse con la misma facilidad para un uno-a-muchos, como en este ejemplo en el que un usuario está asociado con muchos órdenes:

(que no entiendo bien las bases de datos así que por favor me corrigen si he entendido algo .)

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) 
) 

Answer 1

Sí, pero luego dejas la verificación de que la aplicación no tiene muchos para muchos, en lugar de aplicarla dentro de la base de datos.

Answer 2

no hay ninguna razón para que una tabla de unión no podría ser utilizado para una relación de uno a muchos. La pregunta es generalmente una de rendimiento. ¿Por qué hacer que la base de datos se una a una tabla adicional cuando no es necesaria?

Answer 3

Una vez que haya creado una tabla, realmente no tiene un tipo de tabla "Junction", tabla "asociativa", tabla "join", es solo una tabla.

Utilizamos estos términos para describir un motivo específico por el que una entidad (y la tabla resultante) se creó inicialmente. Las entidades asociativas se crean, inicialmente, para resolver una situación de muchos a muchos. Pero estas tablas con frecuencia tienen atributos propios (como el momento de la asociación, una razón para la asociación, etc.). Entonces, SQL Server, Oracle o su código no tienen ninguna razón para saber por qué se creó una tabla ... solo que es una tabla.

Desde un punto de vista técnico, realmente no hay ninguna diferencia entre una tabla asociativa y cualquier otra tabla.

Estas tablas pueden cumplir cualquier rol que cualquier otra tabla pueda cumplir. No existen reglas sobre cómo otras tablas también pueden estar relacionadas con ellas.

Answer 4

Esto sería muchos-a-muchos:

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

Este sería uno-a-muchos (un usuario tiene muchos pedidos):

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

Nota la diferencia en el PRIMARY KEY restricción.

Answer 5

Puede aplicar la restricción de "uno" en la tabla join/junction agregando una restricción única (o convirtiéndola en la clave principal de la tabla join, porque ese atributo identifica la relación) a la columna que es un foreign clave para el lado "muchos". Eso es porque quieres que los rwos en muchos lados tengan una sola relación y las relaciones se establezcan en la tabla de unión/unión.

Answer 6

Creo que tienes el concepto equivocado - Esta es la explicación simple si pudiera ayudar: Para lograr una relación muchos-muchos entre dos tablas (por ejemplo, A y B), tenemos que tener la ayuda de una tabla de unión (por ejemplo, tabla c) que tendrá una relación uno a muchos con las tablas A y B.