在 MySQL 中实现一对一关系时确定外键答案

【问题标题】：Deciding on foreign key while implementing one to one relationship in MySQL在 MySQL 中实现一对一关系时确定外键
【发布时间】：2013-05-27 15:16:44
【问题描述】：

我有两个简单的表“项目”和“订单”。为简单起见，我们假设一件商品只能在一个订单中，或者一个订单只能包含一件商品。

现在因为这可以使用简单的一对一关系来实现，所以我可以执行以下操作：

我可以将订单表的主键添加到项目表中，如下所示

//Table Items
item_id, item_name, order_id
1,        shoes,    1
2,        watch,    2

//Table Orders
order_id, customer
1,        James
2,        Rick

或者我可以将项目表的主键添加到订单表中，如下所示

//Table Items
    item_id, item_name
    1,        shoes
    2,        watch

//Table Orders
order_id, customer, item_id
1,        James,    1   
2,        Rick,     2

哪一个是正确的，为什么？是否有任何指导方针来决定哪把钥匙放在哪里？当然，常识在上面的简单示例中会起作用，但在复杂示例中我们如何决定？

【问题讨论】：

标签： mysql database database-design entity-relationship one-to-one

【解决方案1】：

一对一 关系通常应该简单地合并到一个表中。如果没有任何矛盾，一对一关系可能是未考虑决定的标志。

如果你真的想使用这种关系，完全取决于你把 FK 放在哪里。在应用 FK 时，您可能需要考虑可选性。但是，在 MySQL 中，它仍然不是真正的一对一关系，因为那里不支持延迟键。

【讨论】：

同意。但随后它们将不再是一对一的关系，它们将成为自我参照关系。
@JayBhatt 如果我理解正确，我在这里看不到自引用关系。您是在询问一般原则还是仅针对此特定问题的解决方案？
@JayBhatt 如果没有延迟外键（MySQL 不支持），您根本无法与两个表建立“一对一”关系。您可以拥有的最好的是“一到零或一” - FK 的位置决定了哪一边是哪一边。如果您想要真正的“一对一”，则必须在一张桌子上进行。
一些一对一的关系属于 IS-A 变体，与此问题中给出的示例不同。 IS-A 关系通常是对象建模中称为类/子类的模式的示例，在 ER 建模中称为泛化/专业化。在这种情况下，像class-table-inheritance 那样拆分表通常很有用
我们遇到了类似的问题我们的问题是事务和位置具有一对一的关系。位置包含交易发生地点的信息。经过进一步分析，我们得出结论，Location与Transaction有关，并不独立存在。在某种程度上，这就像一个子实体。因此，我们在 Location 表中使用了事务的外键。