表关系 - 一对多（多）

Question

我知道标题可能看起来令人困惑，但我还没有找到这个设计模式的可靠答案。假设我想创建一个 Employee 表并为每个员工设置多个地址。因此，这将需要您的标准一对多关系。您显然希望 Address Type 列跟踪您为每个员工存储的地址类型。

现在对于我的问题，我希望每个员工的每个地址类型只允许一个地址。这打破了一对多模型，因为我想在数据库级别强制执行此限制。我看到了几种处理此问题的方法，但我坚持根据最佳实践和功能选择哪种方法最好。

下面是删除了 AddressId 的相同表，因为没有用处，取而代之的是 EmployeeId 和 AddressTypeId 的复合主键。这将强制每个员工使用一种地址类型，允许每个员工有多个地址，但每种类型只有一个。

为了在地址表上强制执行密钥限制，这可能会正常工作。但这似乎更像是一对一/无关系，这可能会导致我无法使用这种表设计的 ORM 问题。（如果我错了，请纠正我。）

下面是我所知道的典型桥接表（多对多对多）关系。与上表一样，它处理我想要强制执行的地址类型限制，同时还使每个表结构良好并具有自己的单一主键。这种设计适用于大多数 ORM，并且可能是正确的方法，但它似乎有点矫枉过正，而且似乎打破了多对多关系的含义，因为永远不会有多个员工的地址。

尽管桥表关系设计很复杂，但它是否是最好的使用方法？除了 ORM 可能出现的问题之外，复合键关系是否会导致我没有看到的问题？还是我完全疯了，以错误的方式看待这一切，实际上有更好的方法来处理这种情况？

Answer 1

EmployeeId 和 AddressTypeId 的复合 PK 正是你想要的，你不需要其他任何东西。关系仍然是一对多的关系，至于一个employee，你可能有很多，address不管是家庭住址还是工作地址​​。

如果您可能有多个员工的相同地址，并且多个员工的同一地址可能是不同的类型，那么桥接表很有趣。如果不是这种情况，这张表就显得有些矫枉过正了，而且可能会徒劳地增加更多的复杂性。

TL:DR：第一个解决方案可能是最好的。