将管理员用户与前端用户放在同一个表中是不是很好的数据库设计?

Ste*_*ven 40 sql database sql-server database-design data-modeling

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

用户和管理员应该是具有不同角色的"用户",还是应该在不同的表中拆分?

OMG*_*ies 40

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

这是我使用的基本结构 -

USERS

  • user_id(主键)
  • 用户名

ROLES

  • role_id(主键)
  • ROLE_NAME

USER_ROLES

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

  • 为什么不把role_id放在users表中? (8认同)
  • 解决方案非常好,但用户和用户可以是不同的动物.想想互联网银行,他们可能不会将员工登录与普通客户登录混合在一起. (4认同)
  • @PixMach(旧帖子,但)用户可能已分配了多个角色。即用户可以同时具有“ article_editor”和“ account_manager”角色。因此,“ USER_ROLES”表管理一对多关系。 (4认同)
  • 对于一个简单到一些复杂的解决方案,这很好用.@ user247245在企业级别方面是正确的 - 银行使用PCI合规性等.我们的一些电子商务商店是IBM WebSphere Commerce,我们使用单独的localhost IP和本地机器来访问我们的内部数据库.然后通过单独的防火墙服务器将实时同步到WWW到云负载平衡器. (2认同)
  • 想想上帝管理员。如果我们希望上帝管理员创建角色并向他们授予差异权限(差异模块的)并将角色分配给其他子管理员,那么它将具有针对用户的完全不同的角色系统。那么将用户和管理员结合在一个集成办公自动化模块的复杂管理员角色系统中将是一个坏主意,例如带有 CMS 和 CRM 的企业门户。维护和代码或数据库迁移(用于更新服务器)也是其他内容。此外,在唯一的聚集索引用户名列中,轻型 admins 表比重型用户表更快。 (2认同)

小智 9

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

但另一方面,国家和城市都有一个名字.两者都是地点.他们应该总是在同一张桌子上吗?有时他们在递归模型中.有时它们是分开的.

我的想法......管理员被认为是你系统中用户的"类型"?或者它是真正不同的东西,"用户"类型没有适用于它?这取决于管理员在您的系统中的真正含义.共享结构是沿着城市/州的线路吗?或者是"你是TYPE用户"的共享结构?

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


Est*_*aya 8

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


Guf*_*ffa 6

用户意外成为管理用户的风险不应大于用户意外成为不同用户的风险,这绝对不应该发生.

请注意,如果在单独的表中有常规用户和管理用户,则常规用户表中的用户标识将与管理用户表中的用户标识匹配.您必须确保一种类型的用户ID 永远不会被意外地用作另一种类型.发现可能导致用户ID变为不同用户ID的内容更难发现这样的问题.


Tes*_*son 5

我相信你的问题没有绝对的真理,这取决于你的申请。

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

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