先说结论：一对一通常有几种合理处理方式
一对一联系转换时，可以在任意一方加入另一方主键作为外键，也可以根据业务约束选择更自然的一方。如果两个实体总是同时出现、属性也不多，有些场景还可以合并成一张表。
但考试题不会只看“任意一方”这几个字。它常常会在题干里暗示：哪一方是可选参与，哪一方访问更频繁，哪一方更适合保存对方的引用。
| 处理方式 | 适合场景 | 提醒 |
|---|---|---|
| 在 A 表放 B 的主键 | A 端更适合保存引用，或 A 端总参与联系 | 外键要能表达一对一约束 |
| 在 B 表放 A 的主键 | B 端更适合保存引用，或 B 端总参与联系 | 不要凭表名随意放 |
| 合并成一张表 | 两个实体生命周期高度一致 | 合并后字段不要失去业务语义 |
| 单独建联系表 | 联系本身有重要属性，或约束较复杂 | 一对一不一定必须单独建表 |
怎么判断外键放哪边
老师讲这类题时，通常会让你先看“谁离不开谁”。如果 A 必须对应 B，而 B 不一定对应 A，把外键放在 A 表里往往更自然。这样可以减少空值，也更符合业务含义。
再看访问习惯。如果系统经常从某一方查另一方，那么把外键放在查询起点一侧，有时会让模型更直接。当然考试选择题一般不会让你深入优化性能，主要还是考关系约束是否表达正确。
小例子
一个员工最多有一个工位，一个工位最多分配给一个员工。
如果每个在职员工必须有工位，而工位可能暂时空闲，可以在员工表中保存工位编号。
如果工位管理更独立，也可以在工位表中保存员工编号，但要处理空闲工位。
和一对多、多对多的区别
一对多最常见的口诀是：外键放多端。多对多通常要单独建联系表。一对一没有这么单一的固定答案，所以更要看题干场景。
如果你在一对一题里机械套“外键放多端”，就会发现没有多端可放。这个时候回到业务约束，比背口诀更可靠。
常见错法
第一，看到一对一就默认合并表。合并不是错，但不是所有一对一都适合合并。第二，外键随便放，没有考虑是否会产生大量空值。第三，忘记一对一约束，导致外键虽然有了，却变成了一对多。
复习时建议把一对一、一对多、多对多放到一张表里比较。数据库设计题考的不是背名词，而是看你能不能把业务关系落到表结构。
相关题目解析
下面这些题目和本专题的判断方法关联较强，适合读完概念后回到具体题干里校验理解。
- ER 图中的多对多联系转换成关系模式时怎么处理？ER 模型 / 多对多联系
- ER 图一对多联系转换成关系表时外键放在哪里？ER 图 / 关系模式转换