Объединяющая таблица (объединяющая таблица) может также использоваться для связи "один ко многим"?
Вы можете использовать Requestly Расширение Chrome для перенаправления, отмены, блокировки, изменения заголовков и ... запросов.
Утвердить запросы перед выполнением, например. для запросов AJAX создайте правило перенаправления и укажите его на статический файл JSON или другой скрипт.
Чтобы заблокировать запрос, используйте функцию отмены запроса и установите пользовательский шаблон.
3 ответа
Да, все еще можно сохранять и обеспечивать связь "один ко многим" в соединении table.
В вашем примере вы не применяете никаких ограничений для соединительной таблицы UserOrders , поэтому один заказ может принадлежать двум пользователям (при условии, что это неверно). Чтобы обеспечить это, вы можете сделать OrderKey первичным ключом таблицы соединений UserOrders (или иметь уникальное ограничение для этого столбца). Технически это станет просто отношением многие-к-одному между UserOrders и пользователями , имея при этом однозначное отношение между Заказы и UserOrders .
Я могу придумать только одну причину для разработки отношения многие к одному с использованием таблицы соединений - если вы планируете разрешить отношения многие-ко-многим в будущем и не хотят иметь дело с миграцией данных. Но в то же время вы оплачиваете стоимость хранения и объединения с дополнительной таблицей.
Я могу думать только об одной причине для разработки отношения многие-к-одному с использованием таблицы соединений - если вы планируете разрешить связь многие-ко-многим в будущем и не хочу заниматься миграцией данных. Но в то же время вы оплачиваете стоимость хранения и объединения с дополнительной таблицей.
Я могу думать только об одной причине для разработки отношения многие-к-одному с использованием таблицы соединений - если вы планируете разрешить связь многие-ко-многим в будущем и не хочу заниматься миграцией данных. Но в то же время вы оплачиваете стоимость хранения и объединения с дополнительной таблицей.
Нет причин, по которым таблица соединений не могла использоваться для связи «один ко многим». Обычно речь идет о производительности. Зачем заставлять базу данных присоединяться к дополнительной таблице, когда в этом нет необходимости?
После того, как вы построили таблицу, она действительно не имеют тип «соединительная» таблица, «ассоциативная» таблица, «объединенная» таблица - это просто таблица.
Мы используем эти термины для описания конкретной причины, по которой объект (и результирующая таблица) был первоначально создан. Первоначально ассоциативные сущности создаются для разрешения ситуации «многие ко многим». Но эти таблицы довольно часто имеют собственные атрибуты (например, время ассоциации, причину ассоциации и т. Д.). Итак, у SQL Server, Oracle или вашего кода нет причин знать, почему была создана таблица ... просто это таблица.
С технической точки зрения, на самом деле нет никакой разницы между ассоциативной таблицей и любой другой. другая таблица.
Таким образом, эти таблицы могут выполнять любую роль, которую может выполнять любая другая таблица. Нет никаких правил относительно того, как другие таблицы могут быть связаны с ними.