在多对多关系中强制使用公共外键答案

【问题标题】：Enforcing common foreign key in many-to-many relationship在多对多关系中强制使用公共外键
【发布时间】：2015-06-21 23:07:42
【问题描述】：

我有以下有趣的数据建模问题。我将使用餐馆的例子来说明它：考虑以下三个实体：Restaurant、Location 和Offer。

这些关系很容易表示：一个Restaurant 表；一个Location 表和来自Restaurant 表的FK；和一个Offer 表和来自Restaurant 表的FK。

有趣的问题来了：

该限制的建模一开始似乎很容易：只需使用两个外键创建一个关联表，一个来自Offer 表，另一个来自Location 表。

该解决方案的问题在于，它不会限制我关联不属于同一家餐厅的 offers 和 locations。

如何以更好的方式对此进行建模，以便在数据库级别强制执行该限制？

【问题讨论】：

我可能最终会创建一个链接 restaurant_locations 表来存储餐厅可以拥有的每个位置，然后为该表创建一个外键。
这意味着为每个餐厅创建一个restaurant_locations 表，对吧？
不，此表将在单独的行中存储每个餐厅的所有位置的记录。想象一下具有id, id_restaurant, id_location 的表，后面两列是FKs 到表restaurant 和location。如果您允许在同一位置有两家餐厅，则此模型相当不错。
@ConsiderMe Locations 已经是一个表格，用于存储餐厅可以拥有的每个位置。至少我是这样解释这个模型的，每个位置映射到 1 家餐厅。
@popovitsj 您可能是对的，但没有提及餐厅位置的唯一性（例如同一邮政地址下的共享空间）。我知道这可能是一种罕见的情况，但它有时仍然存在 :)

【解决方案1】：

我的假设是，在您当前的模型中，Location 有 1 家餐厅，Offer 有 1 家餐厅。

您可以通过在 Offer 上创建一个复合键来解决您的问题：(Restaurant_ID, Offer_ID) 并将此键用作从 Location_Offers 到 Offer 的外键。

您可以在 Location 上执行相同操作：创建一个复合键 (Restaurant_ID, Location_ID) 并将其用作从 Locations_Offer 到 Location 的外键。

这可确保 Locations_Offer 中链接 Location 和 Offer 的任何记录仅链接那些与同一家餐厅有关系的记录。

【讨论】：

这就是我要找的。在实践中，我有一些问题浮现在我的脑海中。表 Location_Offers 具有三个字段：restaurant_id、location_id、offer_id。 SQL 数据库是否允许这种奇怪的关系，其中表 Location_Offers 的字段 restaurant_id 将同时属于表 Restaurant 和 Offer 的外键？
我想我会尝试去做并发现它是如何进行的。
您的问题的答案是“是”。一个字段可以同时是一个表的 PK 的一部分，也可以是不同表的多个 FK——假设每个定义本身都是有效的。