..or should I just go ahead and store them right in the users table even though they will mostly b开发者_JS百科e null?
For normalization reasons I would put them in a separate table.
table user
-------------
id integer primary key auto_increment
username varchar
salt_passhash varchar
......
table tokenreset
---------------
id integer primary key auto_increment
user_id integer
when_requested timestamp
all_done boolean default false
If you want to know the users that need to have their passwords reset do:
SELECT u.id, u.username, u.email FROM user u
INNER JOIN tokenreset tr ON (u.id = tk.user_id)
WHERE NOT(tr.alldone)
Or code of that nature.
This way you will not have a field in user
that does not get used 95% of the time.
Either is a valid implementation. It really doesn't matter.
It's not like you're going to have enough users that you care about that extra bit per row to store the fact that the column is NULL. Even if you are Facebook.
精彩评论