I have a freelance web application that lets users register for events. In my database, I have a t_events_applicants table with the column t_events_applications.user_id with a foreign key constraint linked to the t_users.user_id column. So this means only users who have registered with my web application can register for my web application’s events.
My client would now like to allow non-registered users, users who do not have an entry in my t_user table, to register for events. These non-registered users only need to provide their name and email address to register for events.
Should I create a t_temporary_user table with columns name and email and then remove the t_events_applicants.user_id fk constraint? Or should I add un-registered users to the t_user table and then add a column called t_user.type where type can be ‘registered’ or ‘non-registered’?
How do I decide which approach to go with?
A lot of times, I hesitate with either approach. I ask myself, “What if at a later time, a temporary user is allowed to become a fully registered user? Then maybe I should have only a t_user table. But then I also don’t feel good about storing a lot of temporary users in t_user.”
Wouldn’t that basically be a role?
Create a users table, give them a number of roles (many to many users_roles).
In the roles table, you would add a role that allows registering for events and roles for various rights on the rest of your website.
That way it is easy to promote event-only-users to full-fledged-users (add the correct roles) and it will be possible to add other things later (other events, special subscriptions etc).
Most likely you already have such a system in place anyway..