现在搞开发为什么还要用关系型数据库？

[Hanggi]

最近做一个项目，有一个权限管理模块。 因为数据库用的是 MYSQL，所以本人建议基于 RBAC 做一个功能比较完善的权限管理系统以绝后患。 这个系统最基础结构就是 User-Role-Permission 中间用关系表连接的 5 表结构，不管是权限管理还是特权管理感觉都是很好很流行的方案。 结果公司里人说表太多了，把 permission 表去掉然后把特权用 JSON 数组连接放进 Role 表里这样就能省 2 个表了。

我就不理解了，现在的人是 nosql 用太多了还是怎么了，整天想着把数据放进 JSON 字段里，那还用关系型数据库干什么呢？

哪位大佬帮我分析分析利弊。

[maichael]

除非是底层支持 json，不然这种用单个 json 代替的后续维护都很麻烦。

[chendy]

@xkeyideal 请教一下，数据的归属权限 现在比较好的方案是什么呢？

[Hanggi]

@xkeyideal 其实 RBAC 可以把权限分得更细的。或者说有什么更好的权限管理设计吗？分享一下。

[jedrek]

@limuyan44 说得没错
@Hanggi 你可以就你提出的这些问题问负责人，看对方的理由和答案是什么

[Hanggi]

@jedrek
@limuyan44 他就是觉得这个可能实现起来复杂，觉得把表删掉两个更简单。

[Lucups]

楼主没有说什么量级项目。
我觉得还是要先看是项目的大小，然后再判断合不合理。如果只是一个简单的小项目那就无所谓了，怎么快怎么来。

话说，现在的人还在自己写权限模块？主流的框架都有成熟的权限模块了吧...

[12tall]

@est 请教大神。目前设计的用的是 sqlserver 用了 8 个表：用户，角色，科室(闭包表)，权限，再加上中间表。确实感觉表比较多 但是想不到更好的办法了~~~

[Hanggi]

@Lucups 项目不算小项目，但是因为是 2B 的所以用户量可能不会很大。但是项目复杂性是有的。
主要权限不是单纯的路由权限，还有指定资源衍生出来的各种服务的权限。如果只是单纯路由权限可能不需要这样。

[jadec0der]

对，现在 RDB 在互联网公司的主流用法就是不用外键。至于 NoSQL，有 DynamoDB 用还可以，Mongo 靠不住啊

[zhouyou457]

万一特权要更新或者删除怎么办?把所有角色遍历一遍?

[Hanggi]

@zhouyou457 关系表是干嘛的，如果你要把特权 id=100 的特权删掉，只要在关系表里把 permissionId=100 的关系全删掉不就行了吗？还有一种方法就是在特权加一个状态，表示这个特权废弃了。

[xkeyideal]

@Hanggi
@chendy

https://blog.csdn.net/Acceptedxukai/article/details/78297879 在 RABC 基础上进行了一种数据权限实现的封装

[securityCoding]

省他妹 ,这么简单清晰的东西非要按照自己的野路子思路瞎改

[mooncakejs]

实际开发中有一些对象没有单独查询的需求，只是另一个对象的附属。就适合用 Json 字段。

[libook]

数据模型大部分为关系模型就用关系型数据库，数据模型大部分为文档型就用文档型数据库，现在大型业务都不是在一个服务上独立做的，涉及到事务也是平台级别的事务，所以按照数据操作的最小粒度来将不同模式的数据模型拆开，可能是比较好的方式。

像学校、老师、班级、学生这种模型就是典型的关系模型，最好使用关系型数据库；学生学习记录会包含学生、课程等当时的状态快照，所以适合使用文档型数据库；然后在平台级别学生和学生学习记录之间又是关系模型。

又比如正常的业务逻辑使用常用的关系型数据库，涉及到搜索的部分用特殊的数据库（数据存储、搜索引擎方案） Elasticsearch。有的公司是同一份数据同时存在多种数据库里，增加了保障一致性的复杂度，获得了最佳综合性能。

[ttentau1]

@cherryas 这和是不是前端出身没有关系，经验问题吧。我前端用过 node+mongodb 之后毅然决然转 php+mysql 了。json 只适合存储不需要变动的数据，比如日志文件，历史记录之类的。如果频繁修改的数据还用 json 来搞，这个人绝对不专业

[est]

@Hanggi 好吧。这样看起来的确需要 5 个表。如果用 JSON 的话中间表的确是可以直接放进 permission role 表的。

[version]

看企业需求吧.
rbac 其实不适合魔改的国内企业内部架构.很多还要加一个组织的模块.
rbac 给国内企业使用就是每个人一个角色.每个人 n 个 div 角色.维护起来很累的.特别是上级权限更新的时候
然后权限基本是有些是跨部门的.
特别是相关联的其它业务需要下发通知什么的.和数据权限..
如果是自家百来人企业..如果人数不多.
推荐还是 user 对象放一个 role 存 json 然后前端配置可以多选的权限级.这样每个人单纯的权限管理.前端只做适配和可视化整理.页面有角色组.而实际数据库没有角色组.
权限管理对于后台来说是很重要的.对于数据权限也重要.最好根据其它业务来适配最好了.
标准不一定适合企业自己.程序也是.合理不留坑是最好的了.

[niubee1]

你的权限规模有多大啊？几万条记录？十几万条记录？大内存数据库实例里几万条记录不加索引跑得还更快一点，再反过来看看， 要是就这点量的话，存 json 文件启动的时候加载到内存里也毫不维和啊。
上来就先拉关系排几个表开撸的一般都菜， 你做事前先分析下需求先， 确定下规模， 不同规模有不同的玩法。你要说规模庞大你还可以上 LDAP 啊，KeyStone 啊

[zjsxwc]

说实话如果没有上千个 role 需求的话，
把 role 与 permission 都硬编码写到一个 json 文件里就可以了，
要修改或者增加 role 与 permission 的话，直接代码里改下就好了。