Sql server 2008 r2 子表的主键是否正确？

Employee表中的主键应该是什么

Table Stores
(PK) StoreID
{other store columns}

Table Employee
StoreID
EmployeeID
{other employee columns...}

[编辑] 我们的设置是这样的：一名员工始终只属于一家店铺。每个员工都应该有一个唯一的ID（即，即使员工属于不同的商店，他们也不应该有相同的ID）

我认为PK应该是EmployeeID，因为它应该总是唯一的。我的同事认为PK应该与StoreID+EmployeeID复合，但是（理论上）可能会有重复的员工ID。我不完全理解他的推理，但他提到的一点是表现。我不太担心查询性能，因为对于我们的数据库，Employee表从未超过5000条记录。我们确实有其他更大的子表引用StoreID，这是创建这样一个键的有效原因吗

[编辑] 如果您还创建了一个只在EmployeeID上强制唯一性的内部密钥，那么复合PK可以吗？也许有多种方法可以做到这一点，但我想选择最普遍接受的做法

我认为PK应该是EmployeeID，因为它应该始终是 独一无二。我的同事认为PK应该与 StoreID+EmployeeID，但是（理论上）可以 有重复的员工ID

你说的是两件稍有不同的事情

如果您只想标识员工，那么主键可能应该是employee_id，并且商店的id号根本不应该在该表中。但是，另外，如果您想知道员工通常在哪个门店工作，您可以在employees表中包含门店id（并使其

不为NULL

），也可以创建一个单独的表

在我从事这项工作的25多年中，我经常有人告诉我，一名员工只能在一家商店工作。这几乎总是不真实的，甚至在经理们发誓这是真的那一刻。有一次，我们在一个房间里与六名员工“讨论”这件事，他们都在不止一家商店工作。其中一人每周在五家不同的商店工作。所有的经理都知道这一点。当我们指出所有在多家商店工作的人时，经理们仍然坚持每个人只在一家商店工作。（耸耸肩）

我喜欢使用一个单独的表来存储员工当前的带薪工作地点。主要原因是管理层总是想要更多关于这种关系的信息，而不仅仅是那些简单的事实。总是。出勤，守时，总是有别的事情

---

在该表中，您需要一个至少为{store\u id，employee\u id}的复合主键。您可能需要更多的列（有时还需要更多的表），这取决于您希望存储的关于该位置关系的其他信息。您还需要某种管理程序（您可能无法实现自动化），以确保每个员工至少有一个当前的带薪工作地点。（如果您的dbms支持断言，您可以摆脱管理过程。）

如果您的EmployeeID在所有存储中都是唯一的，那么它应该是该表的主键。就像你说的，否则你会有重复的雇员ID。我能看到的拥有StoreID+EmployeeID的唯一原因是，如果每个商店都有自己的员工编号。如果一个人在两个不同的网店工作，他将需要两个员工ID，每个店铺一个。但从你的问题来看，我认为情况并非如此

但是，StoreID应该使用外键关系进行设置，假设总是为员工分配StoreID

---

另外，如果您的同事主要关心性能，您可以向表中添加EmployeeID、StoreID索引，这将清除任何缓慢的查询（如果您遇到任何查询）。因为您说过表很小，所以我会等到出现性能问题后再添加索引。我认为主键总是一个逻辑性的组织决定，我不认为绩效是决定的一部分。

我编辑了我的问题，以便对规则更加清楚。在我们的例子中，员工将始终只属于一个存储，EmpID应该在整个数据库中是唯一的。我的数据库实际上不是关于员工和商店的，我只是把它们作为直观的例子来替代。虽然我同意您的解决方案将适用于真正的员工：）您的交互正确，但empID在整个数据库中是唯一的。我更新了Q以澄清问题。我完全同意您的评估，即PK需要反映表中的唯一列。我不知道我应该现在给你答案还是等一会儿，因为我希望得到更多的评论。由于这是一场口角，我能指出的支持意见越多越好。