让管理员用户与前端用户在同一个表中是好的数据库设计吗?

发布于 2024-10-01 16:40:40 字数 85 浏览 3 评论 0原文

我有可以在前端页面登录的用户,以及可以在管理页面登录的管理员。

用户和管理员应该都是具有不同角色的“用户”,还是应该将它们拆分在不同的表中?

I have users who can login on a front-end page, and admins who can login on an admin page.

Should both users and admins be "Users" with different roles, or should they be split in different tables?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(9

眉目亦如画i 2024-10-08 16:40:40

角色应与用户帐户分开跟踪,因为随着时间的推移,某人可能会晋升(或降级)。在这种情况下,在两个不同的表中拥有两个不同的用户帐户是否有意义?我认为不是。

这是我使用的基本结构 -

USERS

  • user_id (主键)
  • user_name

ROLES

  • role_id (主键)
  • role_name

USER_ROLES

  • user_id (主键,USERS.user_id 的外键)
  • role_id (主键,ROLES.role_id 的外键)

Roles should be tracked separately from user accounts, because someone can be promoted (or demoted) over time. Would it make sense in that situation to have two different user accounts, in two different tables? I think not.

Here's the basic structure I'd use -

USERS

  • user_id (primary key)
  • user_name

ROLES

  • role_id (primary key)
  • role_name

USER_ROLES

  • user_id (primary key, foreign key to USERS.user_id)
  • role_id (primary key, foreign key to ROLES.role_id)
葬心 2024-10-08 16:40:40

是的,所有用户都属于用户表。您还需要有一个 Roles 表并在两者之间有一个 FK。

Yes, all users belong in the users table. You also need to have a Roles table and have a FK betweent the two.

甜味超标? 2024-10-08 16:40:40

用户意外成为管理用户的风险不应大于用户意外成为其他用户的风险,而且这种情况也绝对不应该发生。

考虑一下,如果常规用户和管理用户位于不同的表中,则常规用户表中的用户 ID 与管理用户表中的用户 ID 相匹配。您必须确保一种类型的用户 ID 永远不会被意外用作另一种类型。发现这样的问题比发现可能导致用户 ID 更改为不同用户 ID 的问题更困难。

The risk one a user accidentally becoming an administrative user shouldn't be bigger than a user accidentally becoming a different user, and that should definitely not happen either.

Consider that if you have regular users and administrative users in separate tables, you would have a user id in the regular user table matching a user id in the administrative user table. You would have to make sure that one type of user id could never be accidentally used as the other type. It's harder to spot a problem like that, than spotting something that could cause a user id changing into a different user id.

愁以何悠 2024-10-08 16:40:40

如果管理员和用户共享字段,似乎他们应该放在同一个表中以避免重复结构。他们都有名字和姓氏。两人都是现实世界中的人类。这可能就是应该的方式。

但另一方面,州和城市都有名称。两者都是地点。他们应该总是坐在同一张桌子上吗?有时他们会在递归模型中这样做。有时它们是分开的。

我的想法……管理员是否被认为是您系统中的一种“类型”用户?或者它是真正不同的东西,没有任何“用户”类型适用于它?这取决于管理员在您的系统中的真正含义。共享结构是否沿着城市/州的界限?或者共享结构是否类似于“您是 TYPE 用户”?

但如果有疑问,请将管理员放入用户表中,因为我怀疑它们是否真正分开。您可能希望为两者共享一个身份验证系统。您可能希望共享两者的帐户创建。除非 admin 是一些特殊的东西,只有开发人员在后端使用。

If admin and users share fields it seems they should go in the same table to avoid duplicating structure. They both have a first name and last name. Both are humans in the real world. This is probably the way it should be.

But on the other hand States and Cities both have a name. And both are locations. Should they always go in the same table? Sometimes they do in recursive models. Sometimes they are separate.

My thinking...... is admin considered to be a "type" of user in your system? Or is it something truly different where nothing of type "user" applies to it? It depends on what an admin really means in your system. Is the shared structure along the lines of city/state? Or is the shared structure along the lines of "you are TYPE user"?

But if in doubt go with putting admins in the user table because I doubt they are truly separate. You will probably want to share an authentication system for both. You will probably want to share account creation for both. Unless admin is some special thing only developers use on the back end.

孤独陪着我 2024-10-08 16:40:40

我相信你的问题没有绝对的事实,这取决于你的应用程序。

用户类型可能位于不同表中的两个原因是:

  • 类型的数据结构不同(详细信息/地址等......)
  • 睡个好觉。如果您手动编辑 FK 值(指向用户),则可以避免将任何内容指向前端用户的风险。

I belive there is no absolute truth about your question, it depends on your application.

Two reasons the user-types could be in different tables would be:

  • The types differ in data-structure (detail / address etc..)
  • Good sleep. If you manually edit your FK-values (pointing at a user), you avoid the risk of pointing anything to a frontend-user.
南薇 2024-10-08 16:40:40

我个人会将“用户”保留在一张表中。您决定如何表示角色(例如,作为用户表本身的静态位,或通过高级 RBAC 权限)取决于您的系统的复杂程度。但用户就是用户。

I'd personally keep "Users" in one table. How you decide to represent roles (e.g. as a static bit on the User table itself, or through advanced RBAC rights) depends on how complex your system is. But a user is a user.

人生戏 2024-10-08 16:40:40

创建一个单独的 Roles 表和一个单独的 User_Roles 表。在第一个定义角色中,在第二个中将用户加入到各自的角色中(他们可能有多个角色?)

Make a separate Roles table and a separate User_Roles table. In the first define the roles, in the second join users to their respective roles (it's possible they might have more than one?)

明月松间行 2024-10-08 16:40:40

保留用户应该没有问题,唯一的问题应该是您访问该信息的页面\方法。

实际上,将两者保留在同一个表中会更好,因为它们保存相同的数据类型。

There should be no problem where you keep the users, only problem should be the pages\methods through which you access that information.

It would actually be better to keep both on the same table since they hold the same data type.

峩卟喜欢 2024-10-08 16:40:40

从数据的角度来看,管理员是具有不同角色的用户,这是有道理的。每个用户权限都可以有一个表,将用户与其角色相关联。用户可以拥有多个这样的角色,但归根结底,管理员就是用户。

From a data perspective it makes sense that administrators are users with different roles. There could be a table for each userright, correlating users with their roles. Users can have multiple roles like that, but at the end of the day, an administrator is a user.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文