The users I am concerned with can either be “unconfirmed” or “confirmed”. The latter means they get full access, where the former means they are pending on approval from a moderator. I am unsure how to design the database to account for this structure.
One thought I had was to have 2 different tables: confirmedUser and unconfirmedUser that are pretty similar except that unconfirmedUser has extra fields (such as “emailConfirmed” or “confirmationCode”). This is slightly impractical as I have to copy over all the info when a user does get accepted (although I imagine it won’t be that bad – not expecting heavy traffic).
The second way I imagined this would be to actually put all the users in the same table and have a key towards a table with the extra “unconfirmed” data if need be (perhaps also add a “confirmed” flag in the user table).
What are the advantages adn disadvantages of each approach and is there perhaps a better way to design the database?
The first approach means you’ll need to write every query you have for two tables – for everything that’s common. Bad ™. The second option is definitely better. That way you can add a simple
where confirmed = True(or False) as required for specific access.What you could actually ponder over is whether or not the confirmed data (not the user, just the data) is stored in the same table. Perhaps it would be cleaner + normalized to have all confirmation data in a separate table so you
left join confirmation on confirmation.userid = users.id where users.id is not null(or similar, or inner join, or get all + filter in server side script, etc.) to get only confirmed users. The additional data like confirmation email, date, etc. can be stored here.