Mysql外键必须引用父表的整个主键吗?

时间:2014-01-20 14:02:21

标签: mysql database foreign-key-relationship composite-primary-key

我正在开发一个小型比萨饼送货网站,我遇到了MySQL桌子的一个小问题。

我在Stackoverflow上找到了这个:https://stackoverflow.com/a/10322293/80907

它提到了以下内容:

  • 两张桌子都必须使用INNODB引擎。
  • “在引用表中,必须有一个索引,其中外键列以相同的顺序列为第一列。”

第一个问题并不是真正的问题,但第二个规则是我在摸不着头脑。

这是一个可以订购比萨饼的网站,因此我将所有关于用户及其订单的数据保存在数据库中。

以下是我要撰写的截图:enter image description here

所以我将拥有一个“用户”表和一个“订单”表。用户必须与订单具有一对多的关系。简而言之,订单由创建订单的用户识别。所以它是一对多,识别。

这意味着“订单”表将具有外键,例如“Users_id”。

当您必须为Pizzas表和Orders表之间的多对多关系创建表时会出现问题。

这个表,我们称之为“Order_Details”(MySQL Workbench自动称它为“Orders_has_Pizzas”)必须引用“Orders”和“Pizzas”。

现在,由于“Orders”已经在标识关系中引用了Users表,因此它是“Orders”主键的一部分。

让我们再次得出这条规则:

  • “在引用表中,必须有一个索引,其中外键列以相同的顺序列为第一列。”

这意味着您必须引用整个主键。如果我删除“Order_Users_id”键,尝试创建数据库时会出现1005错误。

我的问题很简单:有没有办法解决这个问题?因为现在,我在3个不同的表中提到了用户ID。

或者,我是否理解不正确,为了不必查询该数据的不同表,是否确实需要这样做?

编辑:人们似乎不同意我的用户和订单之间的关系。

我不知道如何在不知道用户ID的情况下识别单个订单。订单完成后,有人将不得不提供比萨饼,这意味着他们需要知道在哪里提供比萨饼。该数据位于Users表中。因此,Users_id是单个订单的标识的一部分。

无论如何,这就是我的看法。如果我错了,请解释原因。

编辑2:感谢a_horse_with_no_name在数据库方面澄清“身份”的概念,我现在看到了我的逻辑错误。信息可以在评论中找到。

1 个答案:

答案 0 :(得分:2)

要回答原始问题,请不要使用InnoDB外键约束来引用引用表的整个主键。

换句话说,InnoDB中的以下两项工作都是:

mysql> ALTER TABLE Orders_has_Pizzas ADD FOREIGN KEY (Orders_id) 
    REFERENCES Orders (id);
Query OK, 0 rows affected (0.63 sec)

mysql> ALTER TABLE Orders_has_Pizzas ADD FOREIGN KEY (Orders_id,Orders_Users_id) 
    REFERENCES Orders (id, Users_id);
Query OK, 0 rows affected (0.02 sec)

实际上,InnoDB允许外键引用任何索引列,即使它不是主键的一部分:

mysql> CREATE TABLE Foo (fooid INT PRIMARY KEY, nonunique INT, KEY (nonunique));
Query OK, 0 rows affected (0.05 sec)

mysql> CREATE TABLE Bar (barid INT PRIMARY KEY, foo_nonid INT, FOREIGN KEY (foo_nonid) 
    REFERENCES Foo(nonunique));
Query OK, 0 rows affected (0.06 sec)

但是,这不是标准SQL,我不建议这样做。这意味着Bar中的一行可以引用父表Foo中的多行。这意味着这两者在外国主键关系之间的联接可能会意外地创建一种迷你笛卡尔产品。

在Orders表中,复合主键的任一列都可能包含重复项。这意味着Orders_has_Pizzas中的给定行理论上可以引用多个订单。

关于识别关系的问题,我同意Orders与用户有识别关系。也就是说,没有被引用的用户存在订单是没有意义的。

但是在我们使用自动递增机制生成唯一ID的表中,将额外列添加到PK似乎是多余的并且没有必要。为什么我们需要Orders来包含用户ID?只保证id是唯一的,因此足以唯一地对每行进行寻址。

我会说这是一个实际的选择,而理论会引导我们在订单中创建复合主键。

在像Orders_has_Pizzas这样的多对多表格中变得更加清晰。该表与Orders和Pizzas具有识别关系。主键由两个外键组成,一个引用Orders,另一个引用Pizzas。根本不需要自动增量PK。

有些人为多对多表添加多余的自动增量ID,为了约定每个表必须具有单列自动生成的主键。但是没有理论上的实践理由来做到这一点。

CREATE TABLE Orders_has_Pizzas (
  id INT AUTO_INCREMENT PRIMARY KEY, -- what is this column for?
  Orders_id INT,
  Orders_Users_id INT,
  Pizzas_id INT,
);