临时用户表还是合法用户表？
我有一个自由 Web 应用程序，可以让用户注册活动。在我的数据库中，我有一个 t_events_applicants 表，其中包含 t_events_applications.user_id 列，并具有链接到 t_users.user_id 列的外键约束。因此，这意味着只有注册了我的 Web 应用程序的用户才能注册我的 Web 应用程序的事件。
我的客户现在希望允许非注册用户（在我的 t_user 表中没有条目的用户）注册事件。这些非注册用户只需提供姓名和电子邮件地址即可注册参加活动。
我应该创建一个包含名称和电子邮件列的 t_temporary_user 表，然后删除 t_events_applicants.user_id fk 约束吗？或者我应该将未注册的用户添加到 t_user 表中，然后添加一个名为 t_user.type 的列，其中类型可以是“注册”或“非注册”？
我如何决定采用哪种方法？
很多时候，我对这两种方法都犹豫不决。我问自己，“如果稍后某个临时用户被允许成为完全注册用户怎么办？那么也许我应该只有一个 t_user 表。但是我也不太愿意存储大量临时用户在 t_user 中。”
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."
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
这基本上不就是一个角色吗？
创建一个用户表，给他们一些角色（多对多users_roles）。
在角色表中，您可以添加一个角色，允许注册事件和角色以获取网站其余部分的各种权限。
这样，就可以轻松地将仅事件用户提升为成熟用户（添加正确的角色），并且以后可以添加其他内容（其他事件、特殊订阅等）。
无论如何，您很可能已经拥有这样的系统了..
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..
我会采用第二种方法：将它们添加到同一个表中，但使用“类型”列。如果您创建两个用户表，则必须始终检查两者以查找用户等。使用两个表，如何从用户到他们创建的内容建立约束？简单地说，他们是一个用户，只是不同的类型。
如果用户（或其他）表中有 CreateDate 或 LastLogin 日期，则可以在一段时间后删除临时用户。
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.
考虑到新的系统要求，注册用户与非注册用户似乎已成为一种错误的区分。我会将它们全部放在一张桌子上。将站点注册信息保存在单独的表中。您甚至不需要组合表中的类型列，因为您可以确定用户是否通过 JOIN 注册到站点注册表。
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.