Может ли соединительная таблица (таблица соединений) также использоваться для отношений «один ко многим»?

Question

Согласно определению, Junction Table (мост стол/таблица соединений) используется для многих-ко-многим, когда используется как это:

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

Но не мог он быть использован так же, как легко для один-ко-многим отношениям, так как в этом примере, в котором один пользователь связан со многими заказами:

(я не понимаю базы данных хорошо, поэтому, пожалуйста, поправьте меня, если я что-то неправильно .)

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

Да, но тогда вы оставляете чек, чтобы его было мало для приложения, вместо того, чтобы принудительно вводить его в базу данных.

Answer 2

Существует не причина, почему таблица стыка не может быть использована для связи один-ко-многим. Вопрос обычно является одним из показателей. Зачем делать базу данных в дополнение к дополнительной таблице, когда она не нужна?

Answer 3

После того, как вы построили таблицу, у нее действительно нет типа таблицы «Junction», «ассоциативной» таблицы, «join» table - это всего лишь таблица.

Мы используем эти термины для описания конкретной причины, по которой первоначально была создана сущность (и результирующая таблица). Сначала ассоциативные объекты создаются для решения ситуации «многие ко многим». Но эти таблицы нередко имеют свои собственные атрибуты (например, время ассоциации, причина ассоциации и т. Д.). Таким образом, SQL Server, Oracle или ваш код не имеют оснований знать, почему была создана таблица ... просто это таблица.

С технической точки зрения между ассоциативной таблицей и любой другой таблицей действительно нет никакой разницы.

Таким образом, эти таблицы могут выполнять любую роль, которую может выполнять любая другая таблица. Нет правил, касающихся того, как другие таблицы также могут быть связаны с ними.

Answer 4

Это было бы много-ко-многим:

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

Это будет один-ко-многим (один пользователь имеет много заказов):

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

Обратите внимание на разницу в PRIMARY KEY ограничение.

Answer 5

Вы можете принудительно установить «одно» ограничение в таблице соединений/соединений, добавляя уникальное ограничение (или сделав его первичным ключом таблицы соединений, поскольку именно этот атрибут идентифицирует отношение) к столбцу, который является иностранным ключ к «много» стороне. Это потому, что вы хотите, чтобы rwos во многих отношениях имели только одно отношение и отношения, указанные в таблице соединения/соединения.

Answer 6

Я думаю, что вы получили понятие неправильно - вот простое объяснение, если это может помочь: Для достижения Many-Many отношения между двумя таблицами (например, А и В), мы должны принять помощь таблицу соединений (скажем, таблицу c), которая будет иметь отношение «один-много» к обеим таблицам A и B.