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

[Hanggi]

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

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

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

[Hanggi]

@zjsxwc 你的意思是说如果只有 100 个 Role 的话，权限管理都给开发的做是吗？

[charlie21]

@securityCoding 我也觉得这个有现成的解决方案吧，非瞎改什么呢

[zjsxwc]

@Hanggi

权限管理仍旧给运营，
但我回复的意思是 permission 少时，
让开发把 permission 写在一个 json 文件里，
不用数据库表没有毛病，
毕竟你系统有哪些功能都是开发做的。

[xuhongda7]

@xkeyideal 请教现在用什么做权限系统

[Aresxue]

这表还多。。。看样子项目没太大的用户量吧，那目前这么做也没啥问题，然后祈祷项目死掉，千万别大规模商用。。。

[xkeyideal]

@xuhongda7 没懂你问的哪方面，看上面我的一个回复

[Hanggi]

@version
@niubee1 这个跟多少条数据真的关系不大，数据存在复杂性（产品权限，产品下面的项目权限，项目里面的多个服务权限，这些权限再相互交叉的权限），就算只有几百条数据只要复杂度上来了都会变成日后的灾难。
@zjsxwc 这也就是我标题里所提的问题。既然觉得 json 文件没问题，对象存 JSON 没问题，那么用关系型数据库干什么呢？都用 json 文件就好了，或者都用 nosql 就好了。使用关系型数据库的意义是什么呢？
不就是想用一个清晰的结构解决复杂的问题吗？

[vus520]

为了表的数量把问题复杂化的，都是一群没被自己坑过的坑货。

[passerbytiny]

兄弟，你有没有想过，你弄个完整的 RBAC，人家看得懂吗？人家要的不是省下两个表的空间，而是两个表的（面向外行人的）理解难度。

[smallpython]

可以想象当初琢磨着发明 nosql 的人们就是在这样的困惑下开始的,但是只要你的思维不局限于,sql 和 nosql 一定存在一个比另外一个好,另外一个必将被历史淘汰的思维定式里,你就会发现没什么好纠结的.
无论什么技术都是为功能服务的,技术本身不应被信奉

[husinhu]

Mysql 的 proxy user 了解一下

[husinhu]

proxy user

[Felldeadbird]

虽然 MYSQL 已经支持 JSON 操作了，所以这样设计没毛病。

只是我个人觉得，在存储 JSON 时，需要考虑好日后统计数据用。

不过既然是权限管理，一般不涉及这样的统计，主要考虑是今后的权限细分，例如，帐号保护子账户的权限………这时候用 json 去保存，估计结构复杂上来了。

最后就是，不要过度设计就行了。未来的事情未来再说吧，。

[jry]

@Hanggi mysql 支持 json 类型

[akira]

你的疑问没错，所以确实 nosql 发展起来了

[q4336431]

个人认为，无论用哪种方式，都先罗列出利弊，然后讨论取舍，选择利大于弊的方案，如果双方都不赞同对方，那么就让上面决定。

[reus]

如果不是 mysql 8，本身有 json 字段类型的话，这样做就是蠢
就算支持 json 字段，不支持索引 json 内部数据，也是百搭
如果要删除某个 permission，要遍历所有 role ？
检查 permission 时，也遍历所有 role ？
role 少可能还没啥大影响，role 一多，或者设计成默认一个用户一个 role，我看你怎么死
这个就是所谓提前优化，多鸠余

[ziding]

典型的过早优化

[aodeng]

@jedrek 这个方法不错啊，空了试一试

[arthas2234]

要对 permission 进行修改怕是要给整哭了，如果对 mysql 有版本要求，怕是要挨打
对于权限这一块，关系很清晰了，建立好索引都不是事
这种复用性强的功能就应该封装一个兼容性好的库，一劳永逸