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

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

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

我可以将orders表的主键添加到items表中，如下所示

//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

或者我可以将items表的主键添加到orders表，如下所示

//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

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

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

---

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

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