There is no right or wrong way to implement this in the database, it all depends on your needs.
Normally, the registration confirmation by email is done to validate the email address of the user. Your marketing department wants to make sure that when they send marketing campaigns, those campaigns actually reach someone's inbox :). Other reasons to validate the email is to make sure that if the user forgets his password you have a channel on which you can send a reset token.
If the registration key is used just to validate the user's email, you don't even need to store it somewhere, just generate it from the user's data:
a = user id in the database;
b = user email;
c = timestamp of registration;
d = number of hours (or days) that the confirmation key is valid;
e = any other unique things of the user
confirmationKey = sha1(concat(a, b, c, d, e))
You then send the user this confirmation key in the email, and when he replies you regenerate the hash and match it against what the user sent. If the hash matches then you check if the time the user confirmed the registration is less than
c + d. If yes, then the token is valid and still hasn't expired. Of course you need to make sure the confirmation key can't be guessed by anyone, and fields like
c help in that sense. You get the idea...
You now don't need to store anything in a database... unless you need to answer questions about the registration process, like:
- how many users actually confirmed after registration? Maybe some of those who didn't confirm are bots?
- how much time do users usually take to confirm the registration?
- for how many users did the confirmation key expire before they actually confirmed?
After you find out what questions you need to answer (if any) you will also know what you need to store in the database and how.