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