表关系-一对少(多)
我知道标题可能看起来很混乱，但我还没有找到一个可靠的答案，这种设计模式。假设我希望创建一个employee表，并为每个员工创建多个地址。所以这需要你标准的一对多的关系。显然，您希望和addresses列跟踪您为每个员工存储的地址类型。
现在，对于我的问题，我希望每个员工只允许每种地址类型一个地址。这打破了一对多的模型，因为我想在数据库级别强制这个限制。我看到了处理这个问题的几种方法，但我坚持认为哪种方法最适合基于最佳实践和功能。
下面的表与删除AddressId的表相同，因为没有用处，而是EmployeeId和AddressTypeId的复合主键。这将强制每个员工一个地址类型，允许每个员工拥有多个地址，但每种类型中只有一个地址。
为了执行地址表上的关键限制，这可能会很好。但这似乎更像是一对一/无一的关系，这可能会导致我与ORM的问题，与这种表格设计不起作用。(如果我错了，请纠正我。)
下面是我所知道的典型的桥接表(多到多-多对多)关系。它和上面的表一样，处理我想要执行的地址类型限制，同时保持每个表的良好结构，并使用它自己的单数主键。这个设计在大多数ORMs中都能很好的工作，而且可能是正确的方法，但它似乎有点过分，而且它似乎打破了多到多关系的意义，因为永远不会有多个雇员的地址。
桥表关系设计是最好的使用，尽管它的复杂性？除了ORM可能产生的问题之外，复合关键关系会不会引起我看不到的问题？还是我完全疯了，看到这一切都是错误的，而实际上有一个更好的方法来处理这种情况？
回答 3
Database Administration用户
发布于 2016-05-03 15:51:31
EmployeeId和AddressTypeId的复合PK正是您想要的，您不需要其他任何东西。这种关系仍然是一对多的关系，对于一个employee来说，无论是家庭地址还是工作地址，你都可能有很多address。
如果您可能对多个员工具有相同的地址，而对于多个员工来说，相同的地址可能是不同的类型，则桥表很有趣。如果不是这样的话，这个表就太过分了，可能会增加更多的复杂性。
答:第一种解决方案可能是最好的。
Database Administration用户
发布于 2016-05-03 21:22:24
我认为说你的两种解决方案中哪一种更好是过于规定性的。您所需要的只是对{EmployeeID, AddressID}的唯一约束。是否是真正的主键取决于你。拥有不同的主键是非常好的；单字段PKs在一些ORM中确实会更好地工作，并且简单地让所有的PKs都是可预测的是有好处的。
是否要使用“桥表”是独立于唯一约束的问题。例如，您可以用一个代理主键(如果您的ORM需要它)和{EmployeeID, AddressID}上的唯一约束来使用桥表。既然是你提出来的，那么你可能会想要使用它的原因值得一谈。
如果您的数据库所负责的不仅仅是员工和地址，或者您的目标是高可重用性："Address“的概念完全独立于" Employees”的概念，则桥接表提供了很大的好处。是否有其他数据库实体可能有地址？一个Facility？一个Customer？第一种解决方案将很难处理这个问题，因为如果不与Address相关联，Employee就不可能存在。在第二个解决方案中，只需添加更多的桥表。
tl;dr:唯一约束。其他一切都与其他问题有关。
Database Administration用户
发布于 2023-03-02 18:26:38
我觉得第三个ERD更好。然而，我也有供应商，承包商和求职者的地址，所以我想知道什么是最好的方法，以适应整个谜题。
https://dba.stackexchange.com/questions/137376
复制相似问题
腾讯云开发者
