Home/ Questions/Q 8104889
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-06T00:00:07+00:00

What should the Primary key be in the Employee Table? Table Stores (PK) StoreID

  • 0

What should the Primary key be in the Employee Table?

Table Stores
(PK) StoreID
{other store columns}

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

[Edit]
Our setup is such that an employee will always belong to one store only. Every employee should have a unique ID (ie, even if employees belong to different stores, they should never have the same ID).

I think the PK should be EmployeeID only, since it should ALWAYS be unique. My coworker thinks the PK should be compounded with StoreID+EmployeeID, but then it would be (theoretically) possible to have duplicate employee IDs. I don’t entirely follow his reasoning, but one thing he cited is performance. I am not too worried about query performance since for our database the Employee table has never exceeded 5000 records. We do have other, larger child tables that reference StoreID, is this a valid reason to create such a key?

[Edit]
Would the compound PK be okay if you also created an internal key that enforces uniqueness on only EmployeeID? Maybe there are multiple ways to do this, but I want to pick the most accepted practice.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    • 0