子表的正确主键？

Question

员工表中的主键应该是什么？

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是可以的吗？也许有多种方式来做到这一点，但我想选择最被接受的做法。

Answer 1

如果您的EmployeeID在所有商店中都是唯一的，那么它应该是该表的主键。就像你说的，否则你会有重复的EmployeeID。我可以看到有StoreID + EmployeeID的唯一原因是，如果每家商店都有自己的员工编号。如果一个人在两个不同的商店工作，他将需要两个员工ID，每个商店一个。不过，从你的问题来看，我并不认为是这样。

但是，StoreID应该设置为外键关系，假设员工将始终被分配一个StoreID。另外，如果您的同事主要关注性能，则可以向表中添加一个EmployeeID，StoreID索引，以清除任何缓慢的查询（如果遇到任何问题）。既然你说表格很小，我会等到性能问题出现在添加索引之前。我认为主要关键始终是一个合乎逻辑的组织决策，我不会将绩效视为该决定的一部分。

Answer 2

我认为PK应该是EmployeeID唯一的，因为它应该始终是 独特。我的同事认为PK应该与 StoreID + EmployeeID复合，但是然后（理论上） 可能有重复的员工ID。

你在谈论两个稍有不同的东西。

如果你想只有来标识雇员，那么主键应该可能是employee_id，并且商店的ID号根本不应该在该表中。 但是如果您还想知道某位员工通常在哪个商店工作，则可以在employee表中包含store_id（并将其设置为NOT NULL），也可以创建单独的表。

25年来，我一直在做这件事，我经常有人告诉我，一个员工可以在只工作一家商店。这几乎总是不真实的，甚至在经理们宣誓的时刻也是如此是是真的。有一次，我们在一个房间里与六位以上的员工“讨论”这个问题，他们都在不止一家商店工作过。其中一人每星期在五家不同的商店工作。和全部经理知道这一点。当我们指出所有在不止一家商店工作的人时，经理们仍然坚持每个人都只在一家商店工作。 （耸耸肩）

我赞成使用单独的表来存储员工目前的付费工作地点。主要原因是管理总是想要除了只是这个裸露的事实，关于这种关系的更多信息。总是。出勤，计时，总是别的。

在表表中，您至少需要{store_id，employee_id}的组合主键。您可能需要更多的列（有时候还有更多的表），具体取决于您想要存储的关于该位置关系的其他信息。您还需要某种管理程序（您可能会或可能无法自动化）来确保每个员工至少有一个当前付费工作地点。（如果dbms曾支持断言，则可以删除管理过程。）