员工表中的主键应该是什么？
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号根本不应该在那个表中。但是，另外，如果您想知道员工通常在哪个商店工作，您可以将 store_id 包含在 employees 表中（并使其成为NOT NULL），或者您可以创建一个单独的表。
In the 25+ years I've been doing this stuff, I've often had people tell me that an employee can work at only one store. That's almost always untrue, often even at the moment the managers are swearing it is true. One time, we were "discussing" this in a room with half a dozen employees who all worked at more than one store. One of them worked at five different stores every week. And all the managers knew this. When we pointed out all the people who worked at more than one store, the managers still insisted that everyone worked at only one store. (shrug)
I favor using a separate table to store employees current, paid work locations. The main reason is that management always want more information about that relationship besides just that bare fact. Always. Attendance, timekeeping, always something else.
In that table, you'll need a composite primary key of at least {store_id, employee_id}. You might need more columns (and sometimes more tables) than that, depending on what other information you want to store about that location relationship. You'll also need some kind of administrative procedure (which you might or might not be able to automate) to make sure every employee has at least one current, paid work location. (If you dbms ever supports assertions, you can get rid of the administrative procedure.)
If your EmployeeID is unique across all stores, then it should be the primary key of that table. Like you said, otherwise you would have duplicate EmployeeIDs. The only reason I can see to have StoreID + EmployeeID is that if each store had its own employee numbers. If a person worked in two differnet stores, he would then need two EmployeeIDs, one for each store. From your question though, I don't think that is the case.
The StoreID should, however, be setup with a Foreign Key relationship, assuming that the employee will always be assigned a StoreID.
Also, if your co-worker is mainly concerned with performance, you can add an EmployeeID, StoreID index to your table, that should clear up any slow queries (if you encounter any). Since you said the table was small, I would wait until a performance issue appeared before adding indexes. I think the primary key is always a logical organization decision, I wouldn't consider performance as part of that decision.