我应该添加传递式外键吗？

一个简单的例子：有一张客户表。

create table Customers (
  id integer,
  constraint CustomersPK primary key (id)
)

数据库中的所有其他数据都应链接到Customer，因此例如Orders：

create table Orders (
  id integer,
  customer integer,
  constraint OrdersPK primary key (customer, id),
  constraint OrdersFKCustomers foreign key (customer) references Customers (id)
)

假设现在有一个表链接到Orders：

create table Items (
  id integer,
  customer integer,
  order integer,
  constraint ItemsPK primary key (customer, id),
  constraint ItemsFKOrders foreign key (customer, order) references Orders (customer, id)
)

我应该添加一个单独的外键Items来Customers？

...
constraint ItemsFKCustomers foreign key (customer) references Customers (id)

而是一张图片：我应该添加虚线/ FK吗？

编辑：我已经将主键定义添加到表中。我想重申一下我的观点：数据库基本上是客户孤立的，作为一种正确性/安全性措施。因此，所有主键都包含customerID。

我认为这是最初的想法。

首先要注意的是LineItem表上的PK具有三个属性{CustomerID, CustomerOrderNo, OdrerItemNo}，而在您的示例中只有两个。

要注意的第二件事是由于id对属性使用通用名称而导致的混乱。

在CustomerOrderNo理想情况下应（1,2,3 ......）为每一个客户和OrderItemNo（1,2,3 ......）每个订单。

好吧，如果可能的话，这很好，但是需要查询以查找先前的最大值，例如

select max(CustomerOrderNo)
from Order 
where CustomerID = specific_customer ; 

这在高交易量环境中通常不是首选，因此常见的是将这些替换为自动增量，基本上达到了相同的目的。的确，此自动增量现在是唯一的，因此可以用作KEY，但是您可以选择将其作为的必要折中方案OrderItemNo。

因此，进行一些重命名，CustomerOrderNo -> OrderNo然后OrderItemNo-> ItemNo您可能会使用此模型

所以现在如果您看Order以下内容是唯一的

{OrderNo}             -- PK
{CustomerID, OrderNo} -- superkey,  AK on the diagram.

请注意，该消息{CustomerID, OrderNo}会传播到LineItem作为FK。

如果您斜视一下，这很接近您的示例，但是PKs {ItemNo} and {OrderNo}只有-与示例中的两个列PK相反。

现在的问题是，为什么不简化为这样的东西？

很好，但是引入了PATH DEPENDENCE-您不能直接LineItem与之Customer连接，必须Order在连接中使用。

如果可能，我更喜欢第一种情况-您选择自己喜欢的。很显然，没有必要直接从FK LineItem到Customer在这三种情况。

“项目”不应直接引用“客户”，因为这是项目的“订单”所隐含的。因此，您根本不需要“项目”表上的“客户”列。

使用现有外键可确保该项目与客户的关系。

如果orders.id是标识列，请考虑一起删除items.customer。