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

Question

В соответствии с определением, Соединительная таблица (таблица моста / таблица связей) используется для отношений «многие ко многим», когда используется так:

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

Да, все еще можно хранить и применять отношение один ко многим в соединительной таблице.

В вашем примере вы не применяете никаких ограничений к соединительной таблице UserOrders, поэтому один заказ может принадлежать двум пользователям (при условии, что это неверно). Для обеспечения того, чтобы вы могли сделать OrderKey первичным ключом таблицы соединений UserOrders (или иметь уникальное ограничение для этого столбца). Технически это просто станет отношением много-к-одному между UserOrders и Users, тогда как между Orders и UserOrders будет отношение один к одному .

Я могу думать только об одной причине для разработки отношения многие-к-одному с использованием соединительной таблицы - если вы планируете разрешить отношение многие-ко-многим в будущем и не хочу иметь дело с миграцией данных. Но в то же время вы оплатите стоимость хранения и присоединения дополнительной таблицей.

Answer 3

Это будет много ко многим:

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 4

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

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

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

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

Answer 5

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

Answer 6

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