我正在尝试在 Branch 到 BranchEmployee 和 Employee 到 BranchEmployee 之间创建一对一的关系。整个想法是分离在分支机构工作的员工数据。我正在使用 SQL Server Management Studio,但我正在为此苦苦挣扎。在 BranchEmployee 中,BranchID 和 UserID 组合在一起成为表的主键。
非常感谢
屏幕截图如下
我正在尝试在 Branch 到 BranchEmployee 和 Employee 到 BranchEmployee 之间创建一对一的关系。整个想法是分离在分支机构工作的员工数据。我正在使用 SQL Server Management Studio,但我正在为此苦苦挣扎。在 BranchEmployee 中,BranchID 和 UserID 组合在一起成为表的主键。
非常感谢
屏幕截图如下
为什么还要这样做?您可以直接将外键添加到Employee
表中的分支。这将删除一个额外的表并使您的架构更简单。我看到的唯一能让你的设计正常的情况是,如果每个员工要么总是从一个分支移动到另一个分支,要么隶属于多个分支,但这两种情况似乎都不太可能,特别是因为你说你想建模一个 1-1 关系而不是一个NN 关系。
长话短说,删除 BranchEmployees 表。
很可能,您实际上有 1:N 关系或 M:N 关系。
如果用户可以为一个且仅一个分支 (1:N) 工作,那么您可以在 Employee 表中放置一个 BranchID(FK),或者使用“额外”BranchEmployee(Link) 表...只要你放BranchEmployee(Link) 表上 (BranchID, UserId) 的唯一约束。
大多数人更愿意将 BranchID(FK) 放在 Employee 表中,因为那是更少的表。
但是,假设您想隔离该数据,并放置一些有关该关系的元数据。说“员工在这个日期开始在分支机构”,又名 EmployeeBranchStartDate。
那么额外的表就更有意义了。注意我说的是“一点”。
BranchEmployee(Link) (Table)
-----------
BranchEmployeeLinkSurrogateKey
BranchId (FK)
UserId (FK)
EmployeeBranchStartDate (datetime)
(unique on BranchId, UserId)
就个人而言,我现在会选择 BranchEmployee(Link)。因为如果我很有可能需要一名员工在 2 个分支机构工作(这会改变与 M:N 的关系),那么我就不必重新设计所有内容。我可以简单地删除 (唯一的 BranchId, UserId) 约束。Aka,一个小小的预防设计,可以在以后节省很多心痛。