一般后台管理员用户和会员用户是否要分开?

纸牌屋弗兰克
  • 2.7k

如题,一般后台管理员用户和会员用户是否要分开,分成两张用户表,一个会员用户表,一个管理员用户表,如果只用一张表可以吗,哪个更好

回复
阅读 8.4k
7 个回答
✓ 已被采纳

谢邀!

我的职业生涯中几乎所有的前后台管理会员都是分开的,大部分做的都是互联网产品,我觉得我可以总结出几点为什么要这么做:

  1. 业务需求:一般总管理后台都是公司内部使用,不牵涉第三方用户,假设真有第三方的分销商、代理商之类的也会开发一个专门的用户后台

  2. 安全需求:安全在业界达成共识的是没有绝对的安全,那么就要尽可能的考虑病增加被黑的难度,第一层就是把管理后台藏起来(限制IP、不用常用域名、目录等),第二层就算发现了也尽量不要用弱密码,加验证码防暴力破解之类的,然后再其他层面问题,可能还会存在分开部署的需求,独立的话更容易扩展一些满足更多的需求

这是个常见的疑问,也是个好问题。

技术决策没有一定之规。实际上这两种实践都是存在的,也都有不少优秀的应用实例。

一个系统总需要解决验证鉴权,即“你是不是声称的这个人”和“这个人是否可以做这件事”两个问题。

从这个角度来看,根据用户身份进行划分,来确定用户的权限范围,这只不过是实现“鉴权”这个目的的可行方法之一,并无什么神秘之处。

管理员/用户分表,这是划分用户身份的一个相当粗暴的二分手段。其特点是:

  • 非己即彼,两者之间存在着不可逾越的鸿沟,几乎无法切换身份

  • 二者能做的行为之间,几乎不存在产生关联的交叉地带,非黑即白

  • 甚至二者的界面都不用一套

  • 【重要】以上的特性确定下来了就不会再改变

如果你的需求符合以上特点,那么分表就是可以的。否则就不应该分。

但必须指出的是:分表能实现的权限控制,不分表一般都是能做到的。所以为了保留灵活性起见,一般不分表是个好选择,尤其是对于新写的程序(需求可能有频繁变更)更是如此。

楼上的都说得非常精彩。
我站在数据的角度说说我的看法。

开发中,经常有这样的情况,开始建了一张表用于存数据A,后面的开发,接到需求,定义了数据结构,然后发现和这张表就几个字段不一样,然后加上几个字段,就把数据B也存在这个表里了。

这样,最终将搞乱一切。

所以,我的观点的,一个表只存一个数据,保持一致性,减少后期犯错的机会。男人就只能进男厕所。

如果鉴权方式相同, 我觉得存一张表方便.
如果鉴权方式都不相同, 那么还是存储两张表好一点

这种问题还是那个万金油的答案:看需求,具体问题具体分析。

权限这个事有几个粗浅的级别:
1-注册用户只有两种身份:普通用户、管理员,没有更详细的权限管理了,这种你分不分表都一样。
2-对注册用户中至少一种类型的用户需要进行权限管理:从逻辑上说,既然需要进行权限管理了,那就不分表,统一逻辑更容易开发和维护
3-不同用户类型的权限管理方式是不一样的:能不分就不分,但是如果分表可以大大降低系统复杂度,那就分。比如通常的权限是TrueFalse判定,但是可能项目要求用户按vip等级管理,1级最大上传10照片,2级最大上传50张照片这种非TrueFalse判定,非要放在一起可能就很麻烦了,可以考虑分表。

当然从另一个角度来说,开发者说了我就要分(或者我就不分),反正我能实现要求,再麻烦我乐意。你能怎么滴?

管理员与会员账号应该分开存储,管理员要做普通账号的功能操作,应该用一个普通会员的账号来操作,不然系统是处理权限的时候就要用默认规则, 比如管理员默认覆盖会员的所有权限, 但是实际需求可能不是这样

还是一句话,看个人或需求
如果管理员和会员的鉴权方式一样,可以放在一起,不一样最好分开放
对于个人角度来说,我一般不会把用户展示和管理页面写在一起,避免验证

撰写回答
你尚未登录,登录后可以
  • 和开发者交流问题的细节
  • 关注并接收问题和回答的更新提醒
  • 参与内容的编辑和改进,让解决方法与时俱进
你知道吗?

宣传栏