Question

Let’s say I have a table called Users which represents registered users of a website. I also have an AccountActivation table which stores the randomly generated string sent to a new user’s email to verify that email.

The AccountActivation table has UserId column which also happen to be the primary key for the Users table. It also has the ActivationCode column to store the code. Either column could uniquely identify a row in the AccountActivation table.

So if I choose the activation code column as the primary key, I end up having two one-to-one tables with different primary keys. I thought in one to one relationship, the two tables must have the same primary key?

Answer 1

If you choose ActivationCode as PK, then why do you have two one-to-one relations?

The only relation that’s there is

AccountActivation.UserId -> Users.UserId

or what else do you think you suddenly have?

If go do what you suggested, then the table Users has its PK on UserId and table AccountActivation has its PK on ActivationCode – not a problem at all, and there’s no reason not to do it this way.

Which column (UserId or ActivationCode) you pick for the PK of AccountActivation doesn’t matter – that doesn’t influence / disturb the FK relationship between AccountActivation and User, nor does it add an extra one-to-one relationship of any kind …..

If you do choose ActivationCode for the PK of AccountActivation, the only extra step that I would take is creating a nonclustered index on UserId so that queries that join the two tables will benefit from maximum performance.