Temporary users table or legitimate users table?

Question

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."

Answer 1

I would go with your second approach: add them in the same table, but with the Type column. If you create two user tables, you'll have to always check both to find a user, etc. With two tables, how would you have a constraint from the user to something they create? Keep it simple, they are a user, just a different type.

If you have a CreateDate or LastLogin date in the users (or some other) table, you could remove temp users after a certain amount of time.

Answer 2

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..

Answer 3

It sounds like registered users vs. non-registered users has become a false distinction given the new system requirements. I would keep them all together in a single table. Keep the site registration information in a separate table. You don't even need a type column in the combined table since you can determine whether the user is registered with a JOIN to the site registration table.